System and method for shared sessions in communication networks

ABSTRACT

A system, apparatus and method are provided for supporting shared sessions in communication networks. The system, apparatus and method include interoperation between a User Equipment and serving nodes of a communication network. The serving nodes communicate with at least one anchor node of the communication network. In some implementations a shared session identifier and User Equipment identifying component are used to identify a User Equipment within a shared session. In some implementations, a paging notification is used to inform one or more target User Equipment that of a downlink message relating to the shared session.

RELATED APPLICATIONS

The present application is a Continuation of U.S. patent applicationSer. No. 15/881,113 filed on Jan. 26, 2018 entitled “SYSTEM AND METHODFOR SHARED SESSIONS IN COMMUNICATION NETWORKS” the entire contents ofwhich are incorporated by reference, inclusive of all filed referencesand appendices.

FIELD OF THE INVENTION

The present invention generally pertains to the field of shared sessionsin communication networks, and particular embodiments or aspects relateto sharing sessions of different devices in communication networks.

BACKGROUND

Next generation wireless communication networks, such as so-called fifthgeneration (5G) communication networks are being developed to support alarge number of connected electronic devices such as a User Equipment(UE). The large number of connected devices, even if they each onlygenerate small amounts of data, are anticipated to result in more datatransmitted over the networks. In particular, next generationcommunication networks seek to include functionality to accommodate thedeployment of electronic devices that have been described asmachine-type communication (MTC) devices (sometimes referred to as“MTC-type UE”). It will be understood that some such devices may bereferred to as Machine-to-Machine (M2M) devices. MTC devices, such assensors, utility meters, and other automated measurement and reportingdevices may generate a large number of sessions on a communicationnetwork, for example each MTC device may generate one or more sessions,though the bandwidth required for each MTC-type UE may be small. Thelarge number of MTC devices, even if each only generates a small amountof traffic, is considered to be a potential problem for deployments.

Other characteristics of MTC-type communications may includeintermittent, and sometimes unpredictable transmission times, and oftenpredominantly more uplink communications, i.e. transmissions from theelectronic device to the network, than downlink communications, i.e.from the network to the electronic device.

Conventionally, the core network (CN) and, optionally, the radio accessnetwork (RAN) maintain at least one session for each wireless devicethat has attached to, and has been authenticated by, the network.Accommodating at least one separate session for each MTC-type deviceusing current communication methods can lead to higher administrativeand signalling costs that may reduce network availability and add tonetwork congestion. Furthermore, MTC-type device may have additionalconstraints that are not considered to be a problem for a conventionalUE including limited battery power.

The present application relates to the use of shared sessions tominimise network overhead and improve network responsiveness.

This background information is intended to provide information that maybe of possible relevance to the present invention. No admission isnecessarily intended, nor should be construed, that any of the precedinginformation constitutes prior art against the present invention.

SUMMARY

It is an object of the present invention to obviate or mitigate at leastone disadvantage of the prior art.

In some embodiments, a User Equipment (UE) is provided. The UE includinga radio interface for receiving data from and transmitting data to acommunication network; a processor; and; a non-transient memory forstoring instructions that when executed by the processor cause the UE tobe configured to: receive, from a serving node: a paging notificationthat identifies one or more UEs from a group of UEs that comprise ashared session, and a security challenge; transmit, to the serving node:a responding UE identifier (RID), and a challenge response based atleast on the security challenge, and cryptographic keying materialassociated with the shared session; and, receive, from the serving node,downlink data.

In some embodiments a method for a user equipment (UE) of acommunication network is provided. The method comprising the UEreceiving, from a serving node: a paging notification that identifiesone or more UEs from a group of UEs that comprise a shared session, anda security challenge; transmitting, to the serving node: a responding UEidentifier (RID), and a challenge response based at least on thesecurity challenge, and cryptographic keying material associated withthe shared session; and, receiving, from the serving node, downlinkdata.

In some embodiments a network function is provided. The network functionexecuting on a network node of a communication network to act as aserving node, and the network node including: a network interface forreceiving data from and transmitting data to network functions connectedto a network; a processor; and a non-transient memory for storinginstructions that when executed by the processor cause the networkfunction to be configured to: receive, from an anchor node: a sharedsession identifier that identifies a shared session for a group of oneor more UEs; an intended recipient that includes: a target UE identifier(TID) that identifies one or more UEs from the group of UEs thatcomprise the shared session, a security challenge, an expected challengeresponse derived from at least the security challenge and cryptographickeying material associated with the shared session; and, downlink data;transmit the security challenge and a paging notification associatedwith the TID; receive, from a responding UE, a challenge response and aresponding UE identifier (RID); and, if the challenge response matchesthe expected challenge response; and if the RID received from theresponding UE corresponds to the TID received from the anchor node,transmit, to the responding UE, the downlink data.

In some embodiments a method is provided for execution by a serving nodeof a communication network. The method comprising the serving node:receiving, from an anchor node: a shared session identifier thatidentifies a shared session for a group of one or more UEs; an intendedrecipient that includes: a target UE identifier (TID) that identifiesone or more UEs from the group of UEs that comprise the shared session;a security challenge, and an expected challenge response derived from atleast the security challenge and cryptographic keying materialassociated with the shared session; and, downlink data; transmitting thesecurity challenge and a paging notification associated with the TID;receiving, from a responding UE, a challenge response and a respondingUE identifier (RID); and, if the challenge response matches the expectedchallenge response, and if the RID received from the responding UEcorresponds to the TID received from the anchor node, transmitting, tothe responding UE, the downlink data.

Some embodiments of the present invention may provide for reducednetwork signalling and overhead while supporting UE including MTC-typeUE. Some embodiments of the present invention may provide for improvednetwork responsiveness to UE including MTC-type UE.

Some embodiments of the present invention may provide for improvednetwork service to UE, including MTC-type UE, that may be operative toswitch between an inactive power-saving state and an active connectedstate in order to reduce power consumption by the UE.

Embodiments have been described above in conjunctions with aspects ofthe present invention upon which they can be implemented. Those skilledin the art will appreciate that embodiments may be implemented inconjunction with the aspect with which they are described, but may alsobe implemented with other embodiments of that aspect. When embodimentsare mutually exclusive, or are otherwise incompatible with each other,it will be apparent to those skilled in the art. Some embodiments may bedescribed in relation to one aspect, but may also be applicable to otheraspects, as will be apparent to those of skill in the art.

BRIEF DESCRIPTION OF THE FIGURES

Further features and advantages of the present invention will becomeapparent from the following detailed description, taken in combinationwith the appended drawings, in which:

FIG. 1A, is a simplified network diagram illustrating a prior artembodiment of small cell deployment for dual connectivity;

FIG. 1B is illustrates a prior art embodiment of a protocol stack;

FIG. 2 illustrates an embodiment of a network model operative to supportshared sessions;

FIG. 3 is a signalling diagram illustrating an embodiment for sharedsession establishment;

FIG. 4 is a signalling diagram illustrating an embodiment of a procedurefor binding a UE to a shared session;

FIG. 5 is a signalling diagram illustrating an embodiment of an inactivemode uplink data transmission procedure for a shared session;

FIG. 6 is a signalling diagram illustrating an embodiment of an inactivemode downlink data transmission procedure for a shared session;

FIG. 7 illustrates an embodiment of a UEID;

FIG. 8 is a signaling diagram illustrating an embodiment of an uplinktransmission procedure between a UE and a serving node;

FIGS. 9A & 9B are signaling diagrams illustrating embodiments of anuplink transmission procedure between a UE and a serving node;

FIGS. 10A & 10B are signaling diagrams illustrating embodiments of anuplink transmission procedure between a UE and a serving node;

FIGS. 11A & 11B are signaling diagrams illustrating embodiments of anuplink transmission procedure between a UE and a serving node;

FIG. 12 is a block diagram illustrating an embodiment of an uplinkprotocol data unit (PDU) for transmission by a UE;

FIG. 13 is an embodiment of an uplink Rn transfer packet;

FIG. 14A illustrates an embodiment for uplink data packetreconstruction;

FIGS. 14B & 14C illustrate embodiments of a PDCP data PDU without andwith a message integrity check;

FIG. 15 illustrates an embodiment of an Rn downlink PDU;

FIG. 16A is a signaling diagram illustrating an embodiment of a downlinktransmission procedure between a serving node and a UE;

FIG. 16B is a signaling diagram illustrating an embodiment of acontention-based 4-step RA procedure;

FIG. 16C is a signaling diagram illustrating an embodiment of acontention-based 5-step RA procedure;

FIG. 16D is a signaling diagram illustrating an embodiment of acontention-free 4-step RA procedure;

FIG. 17 illustrates an embodiment of a challenge response PDU;

FIG. 18 illustrates an embodiment of a downlink PDU;

FIG. 19 illustrates an embodiment of a delivery status; and,

FIG. 20 illustrates an embodiment of a CN-based anchor node model;

FIG. 21A is a block diagram of an electronic device within a computingand communications environment that may be used for implementing devicesand methods in accordance with representative embodiments of the presentinvention; and,

FIG. 21B is a diagram illustrating a cloud-based implementation of aCore Network and Radio Access Network using virtualized functions.

DETAILED DESCRIPTION

The present application describes embodiments for using shared sessionsto minimise network overhead and improve responsiveness to UEs, and inparticular be capable of extending support to a massive deployment ofelectronic devices such as machine-type communications (MTC) UEs. Insome embodiments, a shared session may be pre-established by the corenetwork allowing individual electronic devices to be subsequentlyassociated with that shared session. In conventional network scenarios,each individual electronic device would be associated with its ownsession. By having a plurality of electronic devices to be associatedwith a single shared session a reduction in the overhead that wouldotherwise have been associated with each of the individual sessions.

An issue for supporting electronic devices, such as UEs and inparticular mobile UEs or power-constrained UEs, is the need for thenetwork to support the UEs when they transition to a low power or “idle”state when their radio functions are inoperative. In order to conservebattery power, UEs may adopt the low power idle state betweentransmissions to minimize power consumption that arises due to radiooperation. In conventional wireless networks, such as those supportingFourth Generation (4G) networks such as Long Term Evolution (LTE)networks or even earlier generations of wireless networks, in the idlestate the no RAN resources associated with the UE are released. As aresult, the UE cannot transmit or receive information while in the idlestate. The UE may transition from idle to a connected state in which theradio connection to the access is re-established. This allows the UE toaccess the network as necessary to exchange information. An issue for3G/4G wireless networks is the associated network signalling that ariseswhen a UE “wakes” from the idle state and returns to the connectedstate. This can be compounded if there are a large number of deviceswaking up at the same time or within a short time window. The networksignalling arises in order to establish a new session with the network,and to re-establish the current UE context after the UE wakes andconnects to the network and identifies itself. Returning to a connectedmode of operation may result in additional latency and extended periodsof time when the UE is active and not able to re-enter a low energy modeof operation due to the required interactions with the network toestablish and maintain the new session. If there is only a small amountof data to be exchanged with the network, such as a single IP packet,the signalling overhead associated with re-connecting to the network andchanging states may be much larger than the amount of data beingexchanged with the UE. This situation may be accentuated for MTC UEswhich may need to periodically connect for short data transfers. Inaddition to the network overhead associated with this signalling, whenan MTC device has limited battery power available, the increasedsignalling can have a negative effect on the life of the MTC device.

In some embodiments a UE operating in a shared session is operative toenter an inactive mode of operation while the network is operative tomaintain the context of the established shared session. When the UE hasinformation to transmit to the network, an uplink packet can betransmitted from within the inactive mode, i.e. without the UE returningto an active connected mode and requesting a new device session. Byobviating the need to enter the active connected mode, signallingoverheads that would normally be incurred by a transition from an idlemode to a connected mode of operation are avoided. Embodiments supportsimilar operations for managing delivery of downlink data while the UEis in the inactive mode.

In some embodiments, support is provided for mobile UEs and otherelectronic devices, which may connect to the network from anywherewithin a service area, without conducting conventional signallingoperations with each of the RAN nodes within the service area. Forinstance, a UE may be operative to identify itself to a local servingRAN node within the service area using a shared session identifier. Eachof the serving RAN nodes operative to obtain relevant context from ananchor node associated with that service area. At least one of theanchor node, and the service area, are identifiable from the groupidentifier received from the UE.

In some embodiments, the shared session identifier may further comprisea group identifier to distinguish between common sessions of a group ofone or more UEs. In some embodiments, such as for MTC-typecommunications, a group of UEs may only have a single associated sharedsession, and the group identifier may also serve as a unique sharedsession identifier for that group. In some embodiments, each sharedsession may be assigned a separate identifier, and accordingly a groupof UEs may have one or more shared session identifiers corresponding tothe session(s) associated with the group. This application uses the term“shared session identifier” to refer to an identifier that at leastdistinguishes between sessions of a particular group of UEs. In someembodiments, the shared session identifier may include a static groupidentifying component and a variable session identifying component todistinguish between sessions of one or more groups of UEs. In theseembodiments, the group identifying component may be exchanged withoutthe session identifying component where it is only necessary to identifythe group and not a particular session of the group.

In some embodiments, the network may be operative to support datatransmissions in both uplink and downlink that are cryptographicallyprotected to validate a connecting UE and to protect against replayattacks. In some embodiments, challenge/response procedures based ongroup keys associated with a group of UEs, provided to each of theconnecting UEs within the group, may be used by all UEs of the group toavoid the establishment of individual security associations for each UE.In some embodiments, the group keys may be provided per shared session.In some embodiments, the group keys may be provided on a per groupbasis. In some embodiments, a plurality of group keys may be provided ona per group or per session basis. In some embodiments, the group keysmay be provided on a per-UE and per-group/session basis. Accordingly,the provision of keys may be aligned with the level of security requiredfor the group.

The present application describes the network and UE functionality usingthe terminology of a currently proposed 3GPP 5G (NR) Radio AccessNetwork, and in particular uses the example of UEs, and other electronicdevices, operating in the 3GPP-defined RRC_INACTIVE state. Thisdescription is intended to be explanatory and non-limiting, and apply toany UE mode where it is desirable to at least one of reduce networksignalling overhead and to maintain UE context at one or more networknodes whether or not the associated UE is connected to a particularnetwork node. The systems and methods described herein may be applied toat least one of similar and equivalent modes of operation in otherstates (e.g. RRC_CONNECTED) and in other radio access technologies (e.g.suspended mode in LTE). Collectively, these modes are referred to as aninactive mode within this disclosure for convenience, but it is notintended to limit application of the invention to a particulardefinition such as RRC_INACTIVE state.

Embodiments of the present invention will be described based on anexample network reference architecture. For the sake of explanatorypurposes, a 5G network is used for explanation, while other networkarchitectures are contemplated. In this example, a radio access network(RAN) node in a 5G system is connected to a core network (CN) controlplane (CP) entity through an interface dubbed NG-C (or N2) and to a CNuser plane (UP) entity through an interface dubbed NG-U (or N3).Throughout this application the terms “network node” and simply “node”are used interchangeably. It should be understood that a network nodecan be a physical node, a network function instantiated on a physicalnode, or a network function instantiated upon computing resources suchas those provided in a data center. In some embodiments, including thosein which the network node or function is within a UP, the node may be avirtualized representation of dedicated hardware (effectively a slice ofa dedicated resource) within a network slice. The CN control planeentity is also connected to UEs through an interface referred to as N1.The N1 control plane messages are conveyed through the RAN node asnon-access stratum (NAS) signalling. A RAN node can also connected be toUEs via a radio link (Uu) and to other RAN nodes via an interfacereferred to as Xn that can include both a control plane component (Xn-C)and a user plane component (Xn-U).

A UE, or other such electronic device, may establish multiple PDUsessions with the CN where different sessions may correspond todifferent instances of the NG-U user plane interface. Each instance ofthe NG-U interface may terminate on a different CN user plane entity.

In other network systems, similar interfaces exist. For example, in anLTE system, a RAN node is connected to a CN through an S1 interface andto other RAN nodes through an X2 interface.

The Uu interface between a UE and a RAN node may comprises severalentities within the protocol stack including physical layer (PHY),medium access control (MAC), radio link control (RLC), packet dataconvergence protocol (PDCP), service data adaptation protocol (SDAP) andradio resource control (RRC) as described, for example, in 3GPP TS38.300 V1.1.0 (2017-10) “NR and NG-RAN Overall Description; Stage 2”.

Control plane information such as RRC and NAS signalling is carried overa signalling radio bearer (SRB) while user plane data is carried over adata radio bearer (DRB).

In some networks, a number of smaller RAN nodes, often referred to assmall cells, picocells or femtocells, may be deployed within thecoverage area of a macro cell to allow for at least one of offloadingtraffic from the macro cell and providing improved service or signalquality to UEs. FIG. 1A, is a simplified network diagram illustrating aprior art embodiment of small cell deployment for dual connectivity. Amaster RAN node 202 provides the NG (or S1) connections 204 to the corenetwork (CN) 206 and maintains a signalling radio bearer (SRB) 208 to aUE 210 through a primary macro cell 212. The UE 210 may use a data radiobearer (DRB) 214 to convey user plane traffic through a secondary cell216 to a secondary RAN node 218. This traffic is relayed between themaster RAN node 202 and the secondary RAN node 218 over an Xn (or X2)interface 220.

Referring to FIG. 1B, a prior art embodiment of a protocol stack isillustrated. On the network side, the user plane protocol stack in adual connectivity deployment is split between the master RAN node 202and the secondary RAN node 218. The master RAN node 202 houses the upperlayer protocol stack entities (including SDAP and PDCP) while thesecondary RAN node 218 houses the lower layer protocol stack entities(RLC, MAC and PHY).

While a UE is registered with the network, it may transition betweenseveral modes of operation, including connected mode (e.g.RRC_CONNECTED), idle mode (e.g. RRC_IDLE) and inactive mode (e.g.RRC_INACTIVE) as described, for example, in 3GPP TS 38.300 V1.1.0(2017-10) “NR and NG-RAN Overall Description; Stage 2”.

The UE context is typically stored at an anchor node while the UE isoperating in the inactive mode. The UE may transition from the inactivemode to the connected mode in a cell that is associated with a differentRAN node, dubbed the new serving node. When this occurs, the UE contextmust be transferred from the anchor node to the new serving RAN node. Inconventional systems, the new serving RAN node then assumes the role ofanchor node for this UE.

Embodiments described within this application provide for a networkoperative to support shared sessions where a plurality of UEs, includingMTC-type UEs, may connect to the network using a common shared sessionthat supports a group of UEs, and for network nodes that support suchfunctionality. The use of such shared, or group, sessions may reducenetwork overhead and improve network responsiveness to UEs transitioningbetween active and inactive modes.

In some embodiments, the anchor node comprises an anchor RAN node. Insome embodiments, the anchor node comprises an anchor network function(anchor NF) executing on a network node. For instance, the anchor NF maycomprise an anchor core network function (CNF) executing on a networknode of the RAN or the core network. In some embodiments, the anchor NFmay comprise a virtualised network function (VNF) executing on a networknode of the RAN or the core network. Operation of the anchor node willinitially be described in the context of an anchor RAN node, which isgenerally applicable to the operation of an anchor NF. Differences inoperation for the anchor NF will be described in more detail inreference to FIG. 20 below.

In some embodiments, the serving node comprises a serving RAN node. Insome embodiments, the serving node comprises a serving network function(serving NF) executing on a network node. For instance, the serving NFmay be executed on a network node of at least one of the RAN and thecore network. In some embodiments, the serving NF may comprise avirtualised network function (VNF) executing on a network node of theRAN or the core network. Operation of the serving node will initially bedescribed in the context of a serving RAN node, which is generallyapplicable to the operation of a serving NF.

FIG. 2 illustrates an embodiment of a network model operative to supportshared sessions. In the embodiment, an anchor node 302 maintains the NGconnections 304 to the core network (CN) 306 for the shared session(e.g. via a 5G NG interface as illustrated, a 4G S1 interface, or otherequivalent interface). The anchor node 302 also maintains, or has accessto, the current configuration and other contextual informationassociated with the shared session.

Referring to FIG. 2, a group RAN notification area (RNA) 301 denotes thecells where UEs 310 311 within the shared session can receive servicewhile roaming within coverage of the network. The scope of the group RNA301 may, for instance, be as small as a single cell or cover as much asthe entire network. If a UE 310 roams outside the designated RNA 301, itmust notify the RAN and may be assigned to at least one of a differentshared session and a different anchor node 302.

The anchor node 302 may be connected via an intra-RAN backhaul network(Rn) 320 to one or more available RAN group target serving nodes 318-1,. . . , 318-n (also referred to as “target serving nodes” or “targetnodes”) within the group. Each of the target nodes 318-1, . . . , 318-nmay control one or more cells associated with the RNA 301 of the sharedsession. The interface 320 between the group anchor node 302 and thetarget nodes 318-1, . . . , 318-n, dubbed Rn 320 in FIG. 2, may besimilar, for instance, to an X2 interface, an Xn interface, a CentralUnit-Distributed Unit (CU-DU) interface, or other similar interface. Atarget node 318-1, . . . , 318-2 is a member of the RAN nodes that areavailable to serve a group member UE. A target node 318-1, . . . , 318-2that is actively serving a UE may be referred to as a “serving node”.Different UEs 310 311 associated with the shared session may beconcurrently served by different target nodes 318-1, . . . , 318-n, i.e.different “serving nodes” of the group of target nodes 318-1, . . . ,318-n, within the group RNA 301. In addition, multiple UEs 310 311associated with the shared session may be concurrently served by thesame target node, e.g. 318-1 as illustrated in FIG. 2.

Based on the embodiment of a RAN architecture of FIG. 2, a UE 310 mayconnect to any of the target nodes 318-1, . . . , 318-n, and be directlyserved as its context is available as being retained as part of theshared session context in the data store accessible to the group anchornode 302, and to the target nodes 318-1, . . . , 318-n, through the Rn320 interface.

The embodiment of FIG. 2 is illustrated using the protocol stack forshared session procedures based on the 3GPP dual-connectivity model forexplanatory purposes. The upper layer SDAP and PDCP protocol entitiesand state machines are located in the anchor node 302. The lower layerRLC, MAC and PHY protocol entities and state machines are located in atleast one of the target nodes 318-1, . . . , 318-n. In this embodiment,and in contrast to the 3GPP dual-connectivity model, the target nodes318-1, . . . , 318-n do not have access to the shared session contextfor managing transmissions over the radio link (Uu) 314. In particular,the target nodes 318-1, . . . , 318-n do not have at least one of (butin some embodiments all of):

-   -   configurations for radio bearers currently established for this        shared session (i.e. RLC configuration, PDCP configuration);    -   radio bearer state information (e.g. received PDU sequence        numbers, transmitted PDU sequence numbers);    -   cryptographic keying material (e.g. keys, counters) associated        with this shared session;    -   QoS information (e.g. authorised QoS profiles, SDAP QoS flow to        DRB mappings);    -   PDU session information (e.g. identity of CN user plane and        control plane functions).

The target nodes 318-1, . . . , 318-n in the embodiment of FIG. 2 lackshared session context, which may allow for reduction or minimization ofthe retention and maintenance of session context information in thenetwork. By reducing retention of session context information, theembodiment reduces network memory requirements, and reduces signallingoverhead that would otherwise be required to maintain the sessioncontext whether or not a particular node of the target nodes 318-1, . .. , 318-n actually provided connectivity to a UE 310 311. Because thetarget nodes 318-1, . . . , 318-n do not maintain radio link protocolinformation, the target nodes 318-1, . . . , 318-n are each operative toemploy shared session procedures to support group sessions.

FIG. 3 is a signalling diagram illustrating an embodiment method 300 ofshared session establishment. In conventional PDU sessions, the CN (orone or more CN functions) establishes a session context within the RANin response to a service request from a UE. By contrast, a sharedsession context may be established by the CN in response to a networkmanagement action and without a UE trigger. For instance, the sharedsession context may be established in advance, of a group of one or moreUEs that are deployed as members of a defined group and are intended tooperate within a shared session. In other embodiments, UEs may be addedor removed from a group after UE deployment, depending uponrequirements.

Referring to FIG. 3, based on a network management action, a CN controlplane function (CPF) 354, executing on a network node of thecommunication network, in step 360, selects a network node to act as theanchor node 350 for this shared session. As discussed above, the anchornode 350 may comprise an anchor RAN node, or may comprise an anchor NFexecuted on a network node of the RAN or the core network. The selectionof the anchor node 350 may, for example, be based on one or more factorsincluding, for example at least one of:

-   -   a configuration provided by the network management system;    -   location of UEs within the target shared session; and    -   load balancing across available anchor nodes.

An anchor node 350 may, for instance, be a selected anchor RAN node thatcomprises a conventional base station (e.g. a gNB or eNB) withsubtending cells. Alternatively, an anchor node 350 may comprise aspecialised mobility anchor network node without subtending cellslocated either in the RAN or CN and serving one or more base stations.The anchor network node may also comprise an anchor network function(e.g. a CNF, VNF, etc.) executing on a network node of the RAN or thecore network. Regardless, this entity is referred to as an anchor node350 within this document.

In step 365 a shared session setup request is transmitted from the CNCPF 354 to the selected anchor node 350. The shared session setuprequest is defined on a group basis, rather than an individual UE basis,and may include, for instance:

-   -   a group identifier (e.g. groupID) that identifies the group of        UEs;    -   at least one of a corresponding network slice identifier (e.g. a        service/slice type, SST) and RAN slice configuration identifier;    -   QoS profiles authorised for this shared session;    -   QoS flow markings associated with the authorised QoS profiles;    -   CN interface configuration for this shared session, including        the transport network layer (TNL) address (@UPGW) used by the CN        user plane gateway (UPGW) 352 for forwarding traffic related to        this shared session;    -   cryptographic keying material associated with the group or with        the shared session.

After receiving the shared session setup request, the selected anchornode 350 generates and in step 370 transmits a shared session setupresponse to the CN CPF 354. The shared session setup response from theselected anchor node 350 may include, for instance:

-   -   a shared session identifier (e.g. groupinactiveID) assigned by        the selected anchor node 350 that references the shared session        context maintained by the anchor node 350;    -   anchor node 350 interface configuration for this shared session,        including the TNL address used by the anchor node        350 (@anchorNode) for forwarding traffic related to this shared        session.

In step 375, the CN CPF 354 may then transmit a session setupinstruction to the CN UPGW 352 to configure the UPGW 352 with the sharedsession information, including the TNL address of the selected anchornode 350 (e.g. @anchorNode), required to deliver downlink packets tomembers of the session group.

In this embodiment, UEs in a group may typically operate in the inactivemode to conserve power and reduce signalling traffic. The use ofgroup-based cryptographic keying material, and the shared sessionidentifier (e.g. groupinactiveID) allows the network to support theshared session while minimizing context information that must bemaintained.

In some embodiments, the CN CPF 354 may create multiple shared sessionsfor a particular group according to service requirements (e.g. QoS,service function chain, external network gateway, etc). The multipleshared sessions may be distinguished from one another by use ofdifferent shared session identifiers for each session. Shared sessionsmay also be created on-demand by the CN CPF (e.g. in response to anetwork attachment request from one or more UEs) or, in some situations,may be pre-configured into network elements, for instance prior todeploying a group of one or more UEs in the field.

There are several procedures that may be used to bind a UE to at leastone of a group and a shared session. For instance, a UE may be bound inresponse to an initial network access request transmitted by the UE. AUE may also be bound in response to an explicit service requesttransmitted by the UE. In some implementations, UEs may be bound throughpre-configuration which may be implemented when the UEs are deployed,likely for MTC-type UEs, or through an over-the-air configurationprocedure to connected UEs belonging to the group.

For UEs which are bound in response to an initial network accessrequest, or an explicit service request transmitted by the UE, thebinding procedures may employ RRC signalling to configure the UEs withshared session-related information that may be used by the UEs in atleast one of subsequent uplink and downlink transmissions.

For UEs which are bound through a pre-configuration process prior todeployment, the procedure need not involve RRC signalling provided thepre-configuration of shared session information may be otherwiseinstalled and activated in the UEs. For instance, UEs may be loaded withthe pre-configured information prior to deployment in the field, or bydirect communication connection to the UEs after deployment in thefield. The direct communication may include, for instance, by cable orshort-range wireless communications (e.g. optical, Bluetooth™, oranother wireless link). In the context of a MTC-type UE such as autility meter, for instance, a service worker may be dispatched at adeployment site to configure, or reconfigure, the UE in place using adirect connection. The direct connection may be useful for at situationsincluding at least one of where the data transfer requirements arehigher than are desired for that UE, there convenience of faultchecking, and for security reasons.

FIG. 4 is a signalling diagram illustrating an embodiment of a procedure400 for dynamically binding a UE 410 to a shared session. In theembodiment of FIG. 4, the UE 410 is bound as a result of an initialnetwork access request transmitted by the UE 410.

In step 415 a, a UE 410 transmits a non-access stratum (NAS) attachmentrequest to an initial node 408 of the network. This may be done in orderto obtain service through a particular RAN or RAN node.

In step 415 b the attach request is forwarded by the initial node 408 toa CN CPF 404 which is typically executed on another network node.Subsequently, in step 415 c, an authentication and authorizationprocedure is conducted between the UE 410 and the CN CPF 404 toauthenticate and authorize the UE 410 for service on the network.

During this procedure, in some embodiments, the CN CPF 404 may identifyone or more shared sessions that have, based on the UE's service profileor other information available to the CN CPF 404, been authorized foruse by this UE 410. If the one or more shared sessions are identified,in step 415 c the UE 410 will further be configured with thecryptographic keying material associated with each of the authorisedgroups or shared sessions.

Following authentication and authorisation of the UE 410, in step 420 athe CN CPF 404 transmits an initial context for the UE 410 to theinitial node 408. For each authorised shared session, the CN CPF 404 mayinclude the shared session identifier (e.g. groupinactiveID) provided bythe designated anchor node 401 during establishment of that sharedsession (e.g. in step 370).

In step 425 a the initial node 408 may identify the designated anchornode 401 for the shared session associated with the shared sessionidentifier (e.g. groupinactiveID). In step 425 b the initial node 408transmits a UE context request to the anchor node 401 for the contextassociated with the shared session. The UE context request may include,for instance, the shared session identifier (e.g. groupinactiveID)corresponding to the shared session.

Responsive to receiving the UE context request, in step 425 c the anchornode 401 transmits a UE context response to the initial node 408. The UEcontext response may include shared session configuration information(groupConfig) which may include, for instance, the group identifier(e.g. groupID) provided by the CN CPF 404 and the logical channelconfiguration for this shared session determined by the anchor node 401.

The shared session configuration information does not necessarilyinclude group cryptographic material or CN connectivity information. Inone embodiment, this security and connection information is retained by,and known only to, the anchor node 401.

Upon receiving the UE context response from the anchor node 401, in step420 b the initial node 408 may transmit an initial context setupresponse to the CN CPF 404 in reply to the initial context setup requesttransmitted by the CN CPF 404 in step 420 a. The initial context setupresponse 420 b confirms receipt of the UE context response 425 c fromthe anchor node 401. In some embodiments the initial context responsetransmitted in 420 b may include some or all of the shared sessionconfiguration information received from the anchor node 401.

In some embodiments, upon receipt of the initial context setup response420 b the CN CPF 404 may transmit, to the initial node 408, an attachresponse 415 d for delivery to the UE 410 in step 415 e.

In step 430, the initial node 408 may transmit radio link configurationinformation to the UE 410 using, for example, radio resource control(RRC) signalling. A configuration exchange may occur, as required, toprovide the UE 410 with a radio link configuration as required foroperations within the initial node 408. The radio link configuration,including shared session information provided by the anchor node 401,may be provided by the initial node 408 to the UE 410 during the RRCreconfiguration in step 430, or at any time before the UE 410 enters aninactive mode of operation.

In step 435, at some future point in time, the initial node 408 mayperform a connection release procedure with the UE 410, prior to the UE410 transitioning to an inactive mode of operation. In an embodiment,the connection release procedure is executed in response to the initialnode 408 determining to release the RRC connection between the initialnode 408 and the UE 410. In an embodiment, the connection releaseprocedure may include an indication transmitted from the initial node408 to the UE 410 instructing the UE 410 to transition into an inactivemode of operation.

For embodiments where a UE 410 is bound to at least one of a sharedsession or a group responsive to an explicit service request, the aboveprocedure may be initiated by a session or service request transmittedby the UE 410 in place of the attach request 415 a. Typically thesession or service request will be transmitted after at least one of aninitial attachment procedure and authentication and authorizationprocedure has been completed. In place of the initial context setuprequest 420 a, the CN CPF 404 can transmit a PDU session establishmentrequest to the initial node 408, in order to exchange thesession-related information, including for instance a shared sessionidentifier (e.g. groupInactiveID) provided by the designated anchor node401 during establishment of that shared session (e.g. in step 370).

In some embodiments, the UE 410 may be assigned to multiple groups andmay be associated with multiple shared sessions, each of which may beassociated with the same, or a different, anchor node 401.

In some embodiments, the UE 410 may be migrated to different groups orto different shared sessions with different anchor nodes 401, e.g. basedon UE mobility or network load balancing.

In some embodiments, a UE 410 may have multiple established PDU sessionsincluding both shared sessions and UE-specific sessions.

FIG. 5 is a signalling diagram illustrating an embodiment of an inactivemode uplink data transmission procedure 500 for a shared session. Theembodiment of FIG. 5 includes security features for validating the UE510, and for prevention of replay attacks.

The UE 510 may initiate a contention-based uplink transmission withinits current serving cell. This is typically performed when there is anuplink PDU queued at UE 510. The contention-based transmission may be anon-orthogonal multiple access, a conventional 4-step random accessprocedure, an optimised 2-step random access procedure or anothergenerally accepted access procedure.

The UE initiates the contention-based uplink transmission by, in step515, transmitting an uplink message to the serving node 508. The servingnode 508 is a RAN node from the group of available target nodes for thegroup RNA. The serving node 508 currently serving the UE 510 may in somecircumstances be the initial node 408 if the UE 510 is still in theservice area of that network node. In some circumstances, however, theUE 510 may have moved from an initial location serviced by the initialnode 408, and the network node that receives a subsequent uplink message(i.e. the serving node 508) may be different from the network node thatreceived the attachment request (i.e. the initial node 408).

The contention-based uplink transmission of step 515 may be scheduledfor transmission within a contention period defined by the serving node508, as is known in the art. The uplink message may include at least thefollowing elements:

-   -   a UE identifier (e.g. UEID) that includes a session identifying        component (shared session identifier), to identify the shared        session associated with a group of one or more UEs to be        associated with this transmission within the RAN service area,        and a UE identifying component to identify a specific UE 510        within the group; and,    -   an uplink data PDU (e.g. rlcData) containing an application        layer user data packet destined for delivery to a remote        corresponding node (RCN) somewhere in the Internet-at-large.

Upon successful receipt of the uplink message, the serving node 508 isable to use the UEID associated with the uplink message to identify theUE 510 making the request, as well as the shared session that themessage relates to.

If the uplink transmission is successfully decoded, the serving node 508responds in step 520 by transmitting a downlink contention resolutionmessage to the UE 510. This downlink contention resolution message caninclude at least the UEID received in the previous uplink transmission.

In some embodiments, the serving node 508 may assign an ephemeral cellradio network temporary identifier (eC-RNTI) to the UE 510 to coordinatefurther contention-free transmissions between the UE 510 and the servingnode 508. The ephemeral C-RNTI is associated with the UE 510 for a shortperiod of time and may be automatically released through expiration of atimer or through conclusion of the inactive mode transmission procedure.

While it is assigned, the eC-RNTI uniquely identifies the UE 510 within(the serving cell of) the serving node 508—i.e. the eC-RNTI is notshared with other UEs of the shared session that may be concurrentlyactive within the serving node 508.

To allow validation of the UE 510 by the anchor node 501, in step 525the serving node 508 initiates a security challenge and responseprocedure with the UE 510. The serving node 508 generates a securitychallenge that typically comprises a random number and transmits thechallenge in a downlink message to the UE 510. When the UE 510 receivesthe challenge, it computes a UE-generated challenge response andtransmits the UE-generated challenge response in an uplink message tothe serving node 508. The UE-generated challenge response is computed bythe UE 510 using at least the challenge provided by the serving node 508and the group cryptographic keying material provided to the UE 510before it entered the inactive mode. In some embodiments, the challengeresponse may be computed, for instance, using a cryptographically securehashing algorithm.

In some embodiments, the serving node 508 is responsible for generatingthe random challenge but not for validating the UE-generated challengeresponse. As indicated in the embodiment illustrated in FIG. 5, theanchor node 501 may be responsible, in step 545, for validating theUE-generated challenge response based on at least one of UE contextinformation, group configuration information, and security information.As explained above, this embodiment allows for group and shared sessioninformation to be held at the anchor node 501, rather than beingdistributed to all target serving nodes.

Based on the UEID received in step 515, in step 530 the serving node 508uses information associated with, or embedded within, the shared sessionidentifier (e.g. groupinactiveID) to identify an anchor node 501corresponding to the shared session for the UE 510.

In step 535, the serving node 508 transmits the uplink data PDU—asreceived from the UE 510—to the anchor node 501. This transmissionbetween the serving node 508 and the anchor node 501 may make use of anintra-RAN (Rn) network connection. In this example, the message sent instep 535 over the Rn connection may include the UEID, the radio linklogical channel identifier (LCID) used by the UE 510 to transmit theuplink data PDU, and the uplink data PDU (e.g. pdcpData) comprisingupper layer 2 (e.g. PDCP and SDAP) protocol headers and an applicationlayer packet. The intra-RAN (Rn) message also includes the randomchallenge provided by the serving node 508 to the UE 510, and theUE-generated challenge response returned by the UE 510.

In step 540 the anchor node 501 determines the shared session associatedwith the PDU based on the shared session identifier (e.g.groupinactiveID) included in the session identifying component of theUEID provided by the UE 510 for the uplink transmission. The anchor node501 can then retrieve the associated shared context information,including group cryptographic keying material and CN connectivityinformation.

In step 545, the anchor node 501 computes an expected challenge responseusing the random challenge provided by the serving node 508 and thegroup cryptographic keying material. The anchor node 501 validates theUE-generated challenge response to confirm the received UE-generatedchallenge response matches an expected challenge response of the anchornode 501 and, if successfully validated, decrypts the received PDU usingthe group cryptographic keying material.

In step 550 a the anchor node 501 encapsulates the application packet(e.g. userData) inside an NG-U tunnel packet and transmits the tunnelpacket to the CN UPGW 502 associated with the corresponding PDU session.In step 550 b the CN UPGW 502 removes the encapsulation and transmitsthe application layer user data packet (e.g. userData) to the remoteserver 504 addressed by the packet.

FIG. 6 is a signalling diagram illustrating an embodiment of an inactivemode downlink data transmission procedure 600 for a shared session. Theembodiment of FIG. 6 includes security procedures for validating the UE610, and for prevention of replay attacks.

In step 615 a the remote server 604 transmits a downlink user datapacket (e.g. userData) that is received by the CN UPGW 602 that isassociated with the shared session. In some embodiments, the CN UPGW 602may be associated with an address (e.g. an IP address or an Ethernetaddress) included in the user data packet that is assigned to the groupof UEs or to the shared session. Responsive to receipt of the downlinkuser data packet, and based on shared session configuration, the CN UPGW602 encapsulates the downlink user data packet in an NG tunnel PDU andin step 615 b transmits the encapsulated downlink user data packet tothe anchor node 601 that is currently serving as the anchor for theshared session.

The anchor node 601 processes the NG tunnel PDU to extract the downlinkuser data packet from the NG tunnel PDU and to identify the sharedsession. The anchor node 601 constructs a downlink PDU by, in step 620,encrypting the extracted downlink user data packet and optionally addingan authenticated message integrity check using the cryptographic keyingmaterial associated with the shared session context. The downlink PDU(e.g. pdcpData) may also include upper layer 2 (e.g. PDCP and SDAP)protocol headers.

The shared session context includes a group RAN notification area (RNA)301 currently assigned to the UE group. From the RNA configuration, instep 625 the anchor node 601 identifies a set of target nodes 609 thatmay have cells encompassed by the RNA. The coverage provided by cells inthe target nodes 609 selected by the anchor node 601 may be larger orsmaller than the nominal coverage area of the RNA.

In step 630 the anchor node 608 transmits the downlink PDU across theintra-RAN (Rn) network to each of the target nodes 609. The downlink PDU(e.g. pdcpData) is encapsulated in an Rn PDU that may also include anyor all of the following information:

-   -   a target UE identifier (TID) to identify at least one UE 610        within the group of UEs associated with the shared session;    -   the logical channel identifier (LCID) to be used for delivery of        the downlink PDU over the radio link;    -   a security challenge; and,    -   the expected challenge response derived from at least the        security challenge and cryptographic keying material associated        with the shared session.

In some embodiments, the TID may comprise a list of target UEidentifiers to identify a plurality of target UEs within the grouptargeted to receive the downlink PDU.

In some embodiments, the TID may comprise a paging identifier associatedwith one or more UEs (or all UEs) of the group that are targeted toreceive the downlink PDU.

In some deployments, the Rn PDU may be forwarded across the intra-RAN(Rn) network as a multicast transmission. In step 635, each of thetarget nodes 609 attempts to locate the target UE(s) 610 in order todeliver the downlink PDU to the targeted UE(s) 610. In some embodiments,the target nodes 609 may be operative to attempt to deliver the downlinkPDU by using at least one of paging and transmission occasions indicatedby the anchor node 601.

At the next transmission occasion or when a target UE 610 responds tothe paging notification in its current serving cell, the now-servingnode 608 attempts to validate the responding UE 610 before forwardingthe downlink PDU by, in step 635, transmitting to the target UE 610 thesecurity challenge received from the anchor node 601 in step 630. Theserving node 608 may further transmit an identifier of the target UE 610(e.g. the TID) with the security challenge. In some embodiments, thetarget nodes 609 are operative to transmit a paging notificationassociated with the TID and the security challenge in a singletransmission. In some embodiments, the target nodes 609 are operative totransmit a paging notification associated with the TID, and then totransmit the security challenge when a responding UE 610 acknowledgesthe paging notification associated with the TID.

The serving node 608 may also assign an ephemeral C-RNTI (eC-RNTI) tothe target UE 610 to coordinate contention-free transmissions betweenthe responding UE 610 and the serving node 608. The ephemeral C-RNTI isassociated with the responding UE 610 for a short period of time and maybe automatically released through expiration of a timer or throughconclusion of the inactive mode transmission procedure.

While it is assigned, the eC-RNTI uniquely identifies the target UE 610within (the serving cell of) the serving node 608—i.e. the eC-RNTI isnot shared with other UEs of the shared session that may be concurrentlyactive within the serving cell of the serving node 608.

Responsive to receiving the security challenge, the target UE 610processes the security challenge to compute a UE-generated challengeresponse based on the security challenge provided by the serving node608 and the group cryptographic keying material provided to the UE 610before it entered the inactive mode. In some embodiments, for instance,the challenge response may be computed using a cryptographically securehashing algorithm. In step 640 the target UE 610 transmits theUE-generated challenge response in an uplink message to the serving node608.

Responsive to receiving the UE-generated challenge response from thetarget UE 610, in step 645 the serving node 608 validates theUE-generated challenge response by comparing the UE-generated challengeresponse with the expected challenge response provided by the anchornode 601 in step 630.

If the UE-generated challenge response does not match the expectedchallenge response provided by the anchor node 601, the serving node 608can abandon the attempt to communicate with the target UE 610. In step660 the serving node 608 transmits a failed delivery status report tothe anchor node 601 indicating an unsuccessful delivery of the downlinkPDU due to a failed challenge response validation.

If the UE-generated challenge response matches the challenge responseprovided by the anchor node 601 in step 630, in some embodiments theserving node 608 uses the assigned eC-RNTI to schedule a downlinktransmission to the target UE 610. The downlink transmission 650 mayinclude an RLC data PDU (e.g. rlcData) constructed by the serving nodethat contains the downlink PDU (e.g. pdcpData) received from the anchornode 601 in step 630.

If the target UE 610 successfully receives the downlink transmission650, and if a reception acknowledgement was requested by the servingnode 608, in step 655 the target UE 610 may transmit a positiveacknowledgement to the serving node 608 (e.g. rlcStatus).

If a delivery status report was requested by the anchor node 601, instep 660 the serving node 608 may transmit an Rn delivery status messageto the anchor node 601, indicating the outcome of the attempted downlinktransmission to the UE(s) 610.

If a target UE 610 successfully receives the downlink transmission 650,it may decrypt and optionally authenticate the downlink PDU (e.g.pdcpData) using its stored cryptographic keying material associated withthe shared session. If the downlink user data packet (e.g. userData) issuccessfully authenticated and reconstructed from the downlink PDU, andif an acknowledgement was explicitly requested by the anchor node 601,in step 665 a the target UE 610 may transmit a delivery status report(e.g. pdcpStatus) acknowledging successful receipt of the downlink PDUto the serving node 608. In step 665 b the serving node 608 transmits tothe anchor node 601 an indication of the delivery status report receivedfrom the UE 610. In an embodiment, the serving node 608 forwards, to theanchor node 601, the delivery status report (e.g. pdcpStatus) indicatingsuccessful receipt of the downlink PDU as the indication.

The forwarding of the downlink PDU to the target nodes 609, along with apaging request, in step 630 is designed to:

-   -   reduce packet delivery delay by avoiding an Rn round trip delay        required to fetch the data packet after receiving a page        response at the serving node 608; and,    -   reduce the time that a target UE 610 must spend out of its low        energy state, i.e. reduce the time spent in an active state, by        minimising the time between the reception of a paging        notification and the scheduling of a downlink transmission for        the user data packet.

In both the uplink and the downlink data transmission procedures, asecurity protocol may be implemented for validating a UE 510 610, and toprevent replay attacks. In some embodiments described herein, thesecurity protocol is based on the use of a security challenge and acorresponding challenge response in order to verify the identity of theUE 510 610. In some embodiments, for instance, the security challengemay include a random component (i.e. a random or pseudo-random number)selected by the serving node 508 for uplink transmissions and by theanchor node 601 for downlink transmissions. In some embodiments, thesecurity challenge is the random component. In some embodiments, thesecurity challenge comprises, at least in part, a sequence component oran identifier component. The sequence component may be used to provideadditional protection from replay attacks. In some embodiments theidentifier component may comprise an indication to another value knownto the UE 510 610 for use in generating the challenge response.

The target UE 510 610 may generate the challenge response from thesecurity challenge, for instance, by calculating a cryptographic hashderived from at least the security challenge and the cryptographic groupkeying material associated with the shared session. In some embodiments,the challenge response is derived, at least in part, from a sequencecomponent or an identifier component. The sequence component may be usedto provide additional protection from replay attacks. In someembodiments the identifier component may comprise an indication toanother value known to the UE 510 610 and to the anchor node 501 601 foruse in generating the challenge response.

The cryptographic hash may be calculated using a cryptographic hashingfunction that is-made-known-to the target UE 510 610. Depending upon thesecurity requirements, the size of the security challenge and thecomputed cryptographic hash may, for instance, be 32 to 256 bits long asa trade-off between security and resource requirements (computational,signalling traffic size, etc.), though other cryptographic strengths(e.g. 512 bits, 1024 bits, etc.) may also be used in some embodiments ifthe security needs offset the additional resource requirements. Thecryptographic hashing function, the size of the security challenge andthe size of the computed cryptographic hash may be “made-known-to” thetarget UE 510 610 as information that may be pre-configured into a UE510 610 (e.g. prior to deployment), or broadcast to all UEs by thenetwork (e.g. in a System Information Block, SIB), or communicatedindividually to each UE 510 610 by the network (e.g. via Radio ResourceControl (RRC) signalling).

In some embodiments, the security challenge may also include anindication of the group key to be used by the UE 510 610 for derivingthe challenge response and for cryptographic operations in subsequentuplink and downlink transmissions associated with this shared session.In some embodiments for uplink transmissions, the group key isidentified by the shared session identifier of the UEID. In someembodiments for downlink transmissions, the group key is associated withat least a target UE identifier (TID) transmitted by an anchor node toone or more target nodes associated with the shared session. In someembodiments, the group key may further be associated with a pagingnotification used by a target node when transmitting to the UE.

In addition to the security challenge and challenge response protocoldescribed above, the UE 510, and the serving node 608 or anchor node501, may be operative to incorporate a sequence number (e.g. a “COUNT”value) provided by a protocol layer, such as the Packet Data ConvergenceProtocol (PDCP) defined by the 3GPP standards. In shared sessions, thePDCP sequence number is not used for in-order delivery of PDCP dataPDUs.

In an embodiment, the PDCP sequence number may be used as a sequencecomponent, as described above, or it may be used as a component or inputto generate a sequence component for use in the cryptographicoperations. In the embodiment, the PDCP sequence number may be leveragedto manage a COUNT value as used by a group of UEs 510 610 associatedwith the shared session, for instance as an input to cryptographic andchallenge/response operations. Since the shared session context isassociated with a group of UEs, additional procedures may be required toseparate or allocate ranges of possible PDCP sequence number values foreach of the UEs 510 610 in the group.

In the case of uplink transmissions, in some embodiments the UE 510 maybe operative to use a range of PDCP sequence numbers as a sequencecomponent of a COUNT input variable used in its cryptographicoperations. Two implementations for using PDCP sequence numbers aredescribed for example:

-   -   In an embodiment, a sequential allocation procedure may be used        in which a UE 510 starts at the lowest value of the assigned        PDCP sequence range and increments the PDCP sequence number        following each uplink transmission. When an incremented sequence        number exceeds the highest value of the assigned range, it is        reset to the lowest value of the assigned range. Combining        sequential allocation with a defined range, allows the anchor        node 501 to partition the PDCP sequence number space for each UE        510 to minimise overlapping use of sequence numbers.    -   In an embodiment, a random allocation procedure may be used in        which a UE 510 randomly selects a number within the assigned        range of PDCP sequence numbers for each uplink transmission.        Random allocation allows a UE 510 to independently select the        PDCP sequence number to be used for an uplink transmission and        may obviate need to coordinate use of sequence number across UEs        in a shared session, while still maintaining sufficient        diversity.

In the case of downlink transmissions, in some embodiments, selection ofa PDCP sequence number by the anchor node 601 may be based on localprocedures. A UE 610 should treat the received PDCP sequence number as arandom number because the anchor node 601 may not assign sequentialnumbers to successive transmissions to a particular UE 610.

In some embodiments, the COUNT value used for cryptographic operationsin both uplink and downlink may be derived from the PDCP sequence numberand an identifier assigned to a UE 510 610 by the anchor node 501. Forexample, the low order bits of the COUNT may be derived from the PDCPsequence number assigned to a PDCP data PDU and the high order bits ofthe COUNT may be derived from an identifier. The identifier may be ashared session identifier (e.g. groupinactiveID), a group identifier(e.g. groupID), a UE-specific identifier, or some other suitableidentifier (e.g. UEID).

While a PDCP sequence number is transmitted in every PDCP data PDU, insome embodiments the identifier can be configured into the UE 510 610(e.g. through RRC signalling) but not transmitted along with a PDCP dataPDU.

In order to support a plurality of UEs associated with a shared session,in some embodiments a number of changes or configurations to the PDCPstack, or its equivalent, currently used for UE-centric sessions may beimplemented. In other embodiments, the PDCP stack, or its equivalent maybe otherwise extended to specifically incorporate shared sessions. Bothembodiments are contemplated.

In the case of a standard PDCP stack for UE-centric sessions, in someembodiments, specific shared session configurations may be implemented.The shared session configuration may be applied at the UE 510 610 foreach data radio bearer (DRB) established for the shared session. Theshared session configuration information may be supplied to the UE 510610, for instance, through RRC signalling, download, pre-definition, orother suitable means of configuring the UE 510 610.

In some embodiments, the Service Data Adaptation Protocol (SDAP) may beconfigured, for instance:

-   -   If only one QoS flow is mapped to a DRB, then transmission of an        SDAP header may be disabled.    -   If reflective DRB mapping is disabled, then transmission of an        SDAP header may be disabled.

In some embodiments, the PDCP may be configured, for instance:

-   -   disable robust header compression (ROHC).    -   disable in-order PDCP data PDU delivery to upper layers.    -   configure PDCP sequence number generation, which may include one        or more of:        -   sequential PDCP sequence number selection;        -   randomised PDCP sequence number selection; and,        -   an assigned range of PDCP sequence numbers.    -   disable check to verify that a received sequence number is        within a pre-defined window.    -   configure security challenge and response size.    -   configure security response cryptographic hashing algorithm.

In some embodiments, the Radio Link Control (RLC) may be configured asrelevant for the communication standard, for instance:

-   -   disable PDU re-ordering if this function is defined by the        communication standard.    -   disable PDU concatenation if this function is defined by the        communication standard.    -   configure appropriate RLC mode of operation, which may include        one of:        -   assured mode (AM), providing segmentation, reassembly and            error recovery through retransmission (ARQ);        -   un-assured mode (UM), providing segmentation and reassembly            but not ARQ error recovery.

The shared session is defined for a specified group of UEs which share acommon session context. The use of a shared session context, in place ofa plurality of unique UE contexts, reduces the overhead required tomaintain the context information. Each UE that is a member of the groupis assigned a UE identifier (UEID) for use in a shared session. The UEIDmay be provided to the UE by the network (e.g. through RRC signalling)at any time before the UE enters an inactive mode of operation. FIG. 7illustrates an example embodiment of a UEID. The UEID 700 includes atleast an anchor node identifier 710, identifying the anchor node for theshared session, and a shared session context reference 720, identifyingthe shared session context information available to the anchor node.Together, 710 and 720 may also be referred to as a shared sessionidentifier (e.g. groupinactiveID) 750. In addition, the UEID 700 caninclude a UE identifying component 730 to distinguish a particular UEfrom other UEs within the group. The embodiment of FIG. 7 identifiesfield contents, but is not indicative of absolute or relative field sizeor order within the UEID 700.

A UE can be provided with a UEID 700 before it enters an inactive mode.When trying to obtain service related to a shared session from a newserving node, the UE can use the previously assigned UEID 700 toidentify itself.

The UE identifying component 730 may be used to identify an individualUE within the group, but it only needs to be unique within the contextof the shared session identifier (e.g. groupinactiveID) 750 because theUE identifying component 730 is defined in combination with the sharedsession identifier 750. Accordingly, the UE identifying component 730only needs to be large enough to cover a maximum number of groupmembers. Accordingly, the UE identifying component may be represented ina much smaller field than would be required to store a globally uniqueUE identifier like a Globally Unique Temporary Identity (GUTI) or anInternational Mobile Subscriber Identity (IMSI).

The UE identifying component 730 may be used by a serving node forcontention resolution to distinguish between contemporaneoustransmissions involving different UEs from the same group.

The UE identifying component 730 may be used by the anchor node todistinguish between different UEs for operational procedures (e.g. foraccounting, for traffic monitoring, for alarm reporting).

The UE identifying component 730 may be either assigned by the anchornode or derived by the UE:

-   -   If there is a need for the anchor node to explicitly identify or        differentiate between individual UEs within a group, a UE        identifying component 730 may be provided by the anchor node        when the UE is bound to the shared session.    -   If the UE is not configured with a UE identifying component by        the anchor node, then the UE identifying component 730 may be        derived by the UE (e.g. directly or via a hash function) from a        persistent identifier that is also associated with the UE. The        persistent identifier may, for example, be provided by the CN        during initial attachment (e.g. Temporary Mobile Subscriber        Identity, TMSI) or during device commissioning (e.g. IMSD.    -   Alternatively, if the UE is not configured with a UE identifying        component by the anchor node, the UE may be operative to choose        a random value to include as the UE identifying component 730 of        the UEID 700 when transmitting the UEID 700 to a serving node.        For security purposes, the UE may be operative to use a        different random value for each uplink or downlink PDU        transmission while operating in an inactive mode.

Uplink Transmission Operations

Uplink data transmission during a shared session in inactive moderequires processing at a serving node to receive an uplink lower layer(e.g. RLC) PDU from the UE and to acknowledge receipt of that PDU. Thisacknowledgement indicates only that the PDU was successfully receivedover the Uu interface between the UE and the serving node. Subsequentvalidation of at least one of the UE and its data can be performed bythe anchor node using the upper layer (e.g. PDCP and SDAP) PDU receivedfrom the serving node. Accordingly, network signalling between thetarget serving nodes and the anchor node may be reduced becausevalidation information does not need to be distributed to all of thetarget serving nodes, many of which may not communicate with aparticular UE associated with a shared session.

Validation may be performed using cryptographic keying material that isknown to all UEs assigned to the shared session. To prevent replayattacks, each uplink transmission is also validated using achallenge/response mechanism in which the serving node provides a randomchallenge variable that the UE must use to generate a response, asdescribed above. In some cases, the challenge/response mechanism adds anadditional step to the basic inactive mode uplink transmissionprocedure.

Embodiments of uplink transmission operations at the serving node willnow be discussed, including:

-   -   4-step Random Access (RA) procedure;    -   2-step RA procedures; and,    -   2-step non-orthogonal multiple access (NOMA) grant-free        procedure.

In these embodiments, the conventional procedures may incorporate thesecurity challenge and response, assuming that the security challengecan be added to a conventional random access response (RAR) transmittedby a serving node to a UE. In some implementations the securitychallenge may be of a length, e.g. 32 to 256 bits, that is too long tofit into a RAR. In these implementations, the security challenge may beprovided in a separate downlink transmission as an additional step toeach of the procedures illustrated below.

Referring to FIG. 8, the baseline uplink procedure 800 (with contention)includes, in step 815, a UE 810 transmits a UEID and optionally uplinkdata to a serving node 808. In step 820, the serving node 808 transmitsa contention resolution message to the UE 810, including at least theUEID. In step 825 the security challenge and challenge response areexchanged between the UE 810 and the serving node 808. In someembodiments, the contention resolution message 820 will be transmittedafter the exchange of security challenge and challenge response in step825. Further steps are discussed above with respect to FIG. 5.

With reference to the baseline uplink procedure illustrated in FIG. 8,FIG. 9A illustrates a conventional 4-step RA procedure 900 a withtransmission of the security challenge in an RAR, and FIG. 9Billustrates a 5-step RA procedure 900 b which provides the securitychallenge in a separate downlink transmission.

For an uplink procedure, in step 915 the UE 910 can select a randomaccess preamble and transmits the random access preamble to the servingnode 908 over a scheduled random access channel (e.g. physical randomaccess channel (PRACH)). As this is a contentious procedure, other UEsassociated with the shared session may be served by the serving node 908and may have separately elected to transmit at the same time, andpotentially may have independently selected the same preamble fortransmission in the PRACH.

In step 920 the serving node 908 can transmit a downlink grant on adownlink control channel (e.g. physical downlink control channel(PDCCH)) using downlink control information (DCI) encoded with apredefined random access RNTI (RA-RNTI) that points to a region in thedownlink scheduled channel (e.g. physical downlink scheduled channel(PDSCH)) that contains a random access response (RAR).

Referring to FIG. 9A, and procedure 900 a, if the security challenge canbe accommodated in the RAR, then in step 925 a the serving node 908transmits a RAR that contains a list of random access preambleidentifiers (RAPIDs) corresponding to the preambles detected by theserving node in the PRACH. For each RAPID, the serving node can provideany or all of:

-   -   a temporary C-RNTI assignment that will later become the        ephemeral C-RNTI (eC-RNTI) used by the UE 910;    -   an uplink grant that may be used by the UE 910 to transmit its        uplink PDU; and,    -   a security challenge generated by the serving node 908.

After receiving the RAR, in step 930 the UE 910 transmits to the servingnode 908 its UEID, buffered data, and a UE-generated challenge responseto the security challenge such that any or all of the following formatsmay be used:

-   -   the UEID may be contained in a MAC control element (CE) with a        CE type indicating the type and structure of the UEID;    -   the buffered data (e.g. rlcData) is contained in a MAC data PDU        element that includes the logical channel identifier (LCID)        corresponding to the data radio bearer (DRB) selected by the UE        910 to convey this information over the radio link; and,    -   the challenge response may be contained in a dedicated MAC        control element (CE) with an appropriate CE type.

Alternatively, the UEID, the challenge response, or both may be includedas fields in the RLC protocol layer header or in the PDCP protocol layerheader.

If the serving node 908 successfully receives the uplink transmission(i.e. the CRC included in the received transmission block is valid), instep 935 the serving node 908 conventionally transmits a downlink grantusing a DCI encoded with the eC-RNTI assigned to the UE 910. In step 940the serving node 908 transmits downlink data including the UEID receivedin step 930 to the UE 910.

After receiving the downlink data transmission in step 940 that includesthe UEID, the UE 910 can compare the UEID contained in the contentionresolution identity MAC CE of the received message 940 against its ownUEID (i.e. the UEID transmitted in step 930):

-   -   if there is a match, uplink transmission of the data is deemed        successful.    -   if there is not a match, uplink transmission of the data is        deemed unsuccessful (e.g. another UE 910 may have transmitted        the same preamble in step 915) and the UE 910 terminates the        procedure; the UE 910 may attempt to retransmit the data by any        number of different procedures including by repeating this        procedure at a later time.

Referring to FIG. 9B, and the variant procedure 900 b, if the securitychallenge cannot be accommodated in the RAR, then in step 925 b theserving node 908 transmits a RAR that contains a list of random accesspreamble identifiers (RAPIDs) corresponding to the preambles detected bythe serving node 908 in the PRACH. For each RAPID, the serving node 908can provide any or all of:

-   -   a temporary C RNTI assignment that will later become the        ephemeral C-RNTI (eC-RNTI) used by the UE 910; and,    -   a downlink grant that will be used to transmit the security        challenge. This is distinct from conventional procedures in        which a conventional RAR includes an uplink grant, and not a        downlink grant.

In step 932, the serving node 908 uses the radio resources indicated inthe downlink grant to transmit a security challenge and an uplink grantto the UE 910.

After receiving the uplink grant, in step 934 the UE 910 transmits tothe serving node 908 its UEID, buffered data (e.g. rlcData), and aUE-generated challenge response to the security challenge. Further stepsare discussed above with respect to FIG. 9A.

FIG. 10A illustrates a conventional 2-step RA procedure 1000 a withtransmission of the security challenge in an RAR, and FIG. 10Billustrates a 3-step RA procedure 1000 b required to provide thesecurity challenge in a separate downlink transmission.

For an uplink procedure, the UE 1010 can arbitrarily select a randomaccess preamble and transmits the preamble in a scheduled random accesschannel (e.g. physical random access channel (PRACH)). As this is acontention-based procedure, other UEs associated with the shared sessionmay be served by the serving node 1008 and may have separately electedto transmit at the same time, and potentially may have independentlyselected the same preamble for transmission in the PRACH. Using uplinkresources associated with the selected preamble, in step 1020 the UEtransmits its UEID and buffered data to the serving node 1008. Thistransmission may be formatted such that at least one of the followingformats may be used:

-   -   the UEID may be contained in a MAC control element (CE) with a        CE type indicating the type and structure of the UEID; and,    -   the buffered data (e.g. rlcData) may be contained in a MAC data        PDU element that includes the logical channel identifier (LCID)        corresponding to the data radio bearer (DRB) selected by the UE        1010 to convey this information over the radio link.

In step 1025 the serving node 1008 transmits a downlink grant using aDCI encoded with a predefined random access RNTI (RA-RNTI) that pointsto a region in the PDSCH that contains a random access response (RAR).

Referring to FIG. 10A, if the security challenge can be accommodated inthe RAR, in step 1030 the serving node 1008 can transmit to the UE 1010a RAR that contains a list of random access preamble identifiers(RAPIDs) corresponding to the preambles detected by the serving node inthe PRACH. For each RAPID, the serving node 1008 can provide any or allof:

-   -   a contention resolution identity containing the UEID received by        the serving node 1008 in step 1020;    -   a temporary C-RNTI assignment that will later become the        ephemeral C-RNTI (eC-RNTI) used by the UE 1010;    -   an uplink grant that may be used by the UE 1010 to subsequently        transmit its challenge response; and    -   a security challenge generated by the serving node 1008.

After receiving the RAR, the UE 1010 can compare the UEID contained inthe contention resolution identity of step 1030 against its own UEID(i.e. the UEID transmitted in step 1020).

-   -   if there is a match, uplink transmission of the data can be        deemed successful and the UE 1010 proceeds to step 1035; and,    -   if there is not a match, uplink transmission of the data can be        deemed unsuccessful (e.g. another UE 1010 may have transmitted        the same preamble in step 1015) and the UE 1010 can terminate        the procedure; the UE 1010 may attempt to retransmit the data        through any of a number of different techniques including by        repeating this procedure at a later time.

Following a successful match, in step 1035, and using the uplink grantprovided in step 1030, the UE 1010 can transmit the UE-generatedchallenge response to the serving node 1008. In some embodiments, theUE-generated challenge response may be contained in a dedicated MACcontrol element (CE) with an appropriate CE type.

Referring to FIG. 10B, if the security challenge cannot be accommodatedin the RAR, then in step 1032 the serving node 1008 transmits a RAR thatcontains a list of random access preamble identifiers (RAPIDs)corresponding to the preambles detected by the serving node in thePRACH. For each RAPID, the serving node 1008 provides at least one of:

-   -   a contention resolution identity containing the UEID received by        the serving node 1008 in step 1020;    -   a temporary C-RNTI assignment that will later become the        ephemeral C-RNTI (eC-RNTI) used by the UE 1010; and,    -   a downlink grant that will be used to transmit the security        challenge to the UE 1010. This is distinct from conventional        procedures in which a conventional RAR includes an uplink grant,        and not a downlink grant.

Following transmission of the RAR, in step 1034 the serving node 1008,using the downlink grant indicated in the RAR, transmits to the UE 1010at least one of:

-   -   an uplink grant that may be used by the UE 1010 to transmit its        uplink PDU; and,    -   a security challenge generated by the serving node 1008.

The remaining steps in FIG. 10B performed by the UE 1010 are the same asthe steps in FIG. 10A.

FIG. 11A illustrates a 2-step NOMA grant-free procedure 1100 a withtransmission of the security challenge in a contention transmissionresponse (CTR), and FIG. 11B illustrates a 3-step NOMA grant-freeprocedure 1100 b required to provide the security challenge in aseparate downlink transmission.

For an uplink procedure, in step 1115 the UE 1110 uses a contentiontransmission unit (CTU) to transmit its UEID and buffered data (e.g.rlcData) to the serving node 1108. The CTU that is used may have beenarbitrarily selected by the UE 1110, or may have been previouslyassigned to the UE 1110, or may have been derived algorithmically by theUE 1110. Other UEs may have independently decided to transmit on thesame CTU.

If an asynchronous acknowledgement is used, in step 1120 the servingnode 1108 transmits to the UE 1110 a downlink grant using a DCI encodedwith a predefined contention transmission RNTI (CT-RNTI) that points toa region in the PDSCH that contains a contention transmission response(CTR). Step 1120 is not required if the CTR is a synchronousacknowledgement using a downlink resource associated with the CTU.

Referring to FIG. 11A, if the security challenge can be accommodated ina contention transmission response, the serving node 1008 can transmit aCTR to the UE 1110 that includes the security challenge. The CTR cancontain a list of contention transmission unit identifiers (CTUIDs)corresponding to the CTUs where an uplink transmission was detected bythe serving node. For each CTUID, the serving node provides at least oneof:

-   -   a contention resolution identity containing the UEID received by        the serving node in step 1115;    -   a temporary C-RNTI assignment that will later become the        ephemeral C-RNTI (eC-RNTI) used by the UE 1110;    -   an uplink grant that may be used by the UE 1110 to subsequently        transmit its challenge response; and,    -   a security challenge generated by the serving node 1108.

Referring to FIG. 11B, if the security challenge is to be provided in aseparate downlink transmission, in step 1127 the serving node 1008transmits a CTR to the UE 1110 that includes a downlink grant (DL grant)rather than the security challenge. The CTR contains a list ofcontention transmission unit identifiers (CTUIDs) corresponding to theCTUs where an uplink transmission was detected by the serving node 1108.For each CTUID, the serving node 1108 provides at least one of:

-   -   a contention resolution identity containing the UEID received by        the serving node 1108 in step 1115;    -   a temporary C-RNTI assignment that will later become the        ephemeral C-RNTI (eC-RNTI) used by the UE 1110; and,    -   a downlink grant that will be used to transmit the security        challenge to the UE 1110.

In step 1129, the serving node 1108, using the downlink grant indicatedin the CTR, transmits to the UE 1110 at least one of:

-   -   an uplink grant that may be used by the UE 1110 to transmit its        challenge response; and,    -   a security challenge generated by the serving node 1108.

Responsive to receiving the security challenge, the UE 1110 generates achallenge response and, using the uplink grant, in step 1130 the UE 1110transmits to the serving node 1108 its computed UE-generated challengeresponse. In some embodiments, the UE-generated challenge response maybe contained in a dedicated MAC control element (CE) with an appropriateCE type.

FIG. 12 is a block diagram illustrating an embodiment of an uplink PDU1200 for transmission by a UE to a serving node.

The PDU 1200 contains at least a UEID MAC element 1201 for the UEID anda data MAC element 1202 for the data. In some embodiments, the PDU 1200may further include a response MAC element 1203 for the challengeresponse.

In the embodiment of FIG. 12, the UEID MAC control element (CE) 1201includes any or all of the following fields:

-   -   a MAC element header 1205 indicating that it is Control element        of type “sessionID_t”, where “sessionID_t” is a predefined        value; and,    -   a UEID field 1210 storing the UEID assigned to, or derived by,        the UE for use in inactive mode operations.

The inclusion of the UEID MAC CE 1201 may indicate to the serving nodethat the UE has initiated an uplink data transmission while in inactivemode. The type or structure of the UEID MAC CE 1201 can allow theserving node to distinguish between a dedicated UE session and a sharedsession. Accordingly, the UEID MAC CE 1201 identifies the uplink datatransmission as a shared session communication.

The data MAC element 1202 may include one or more of the followingfields:

-   -   a MAC element header 1220 indicating that this is a Data        element; this field also includes the logical channel identifier        (LCID) associated with the data radio bearer (DRB) selected by        the UE for conveying the user plane data over the uplink;    -   a length field 1230 indicating the length of the data PDU (i.e.        indicating the size of the MAC data element 1202), for instance        in a number of octets;    -   a Radio Link Control (RLC) header 1240;    -   a Packet Data Convergence Protocol (PDCP) header 1250;    -   a Service Data Adaptation Protocol (SDAP) header 1260; and,    -   a user plane data field 1270, containing the data (information)        destined for a remote corresponding node connected to the        Internet-at-large.

The response MAC element 1203 may include one or more of the followingfields:

-   -   a MAC element header 1280 indicating that it is Control element        of type “response_t”, where “response_t” is a predefined value;        and,    -   the challenge response 1290 computed by the UE.

In a 4-step RA procedure, or a 5-step RA procedure, as described above,the response MAC CE, UEID CE and data PDU can be transmitted together inthe same MAC PDU. In the 2-step RA procedure, the 3-step RA procedure,and in the NOMA grant-free procedure described above, the challengeresponse MAC CE can be transmitted in a separate MAC PDU. Other MACcontrol elements may also be included as required (e.g. buffer statusreport, BSR).

In some embodiments, asynchronous HARQ may be used for recovery fromtransmission errors following the assignment of an eC-RNTI to the UE bythe serving node.

In some embodiments, RLC procedures may be used to transmit an uplinkPDU that must be segmented across multiple transport blocks. These RLCprocedures make use of the eC-RNTI assigned to the UE by the servingnode.

Once the serving node has successfully received a complete uplink RLCPDU, the upper layer PDU headers (at least one of PDCP and SDAP) anduser data are forwarded over an intra-RAN (Rn) network to the anchornode. In some embodiments, the anchor node has been identified by theUEID associated with the transmission. Referring to FIG. 13, anembodiment of an intra-RAN (Rn) message 1300 used to transfer the PDUover the Rn interface between the serving node and the anchor node mayinclude any or all of the following information:

-   -   a UE reference 1305, comprising at least the UEID 700 as        received from the UE;    -   the serving node security challenge 1310 issued by the serving        node and the UE-generated challenge response 1315 provided by        the UE;    -   the LCID 1320 included in the MAC data element by the UE; and,    -   the upper layer data (e.g. pdcpData) 1322 received from the UE,        including one or more of:        -   PDCP header 1325;        -   SDAP header 1330, if provided by the UE; and,        -   the user data 1335 for forwarding to a remote corresponding            node.

When an uplink RLC PDU is successfully received from the UE by a servingnode, the user data and the upper layer (e.g. at least one of PDCP andSDAP) headers are forwarded to the anchor node along with the UEIDprovided by the UE. Upper layer procedures for a shared session (e.g.PDCP and SDAP procedures) are subsequently performed in the anchor node.

Referring to FIG. 14A, an embodiment of a method 1400 for uplink datapacket reconstruction is presented. In some embodiments, the method maybe executed by the anchor node.

In step 1402, the anchor node retrieves the context associated withshared session based on the shared session identifier (e.g.groupinactiveID) included the UEID provided by the UE. In particular,retrieving the context associated with the shared session may includethe anchor node being operative to obtain at least one of:

-   -   the cryptographic parameters currently associated with the group        or with the shared session (e.g. cryptographic keys and        algorithms); and,    -   RRC configuration parameters associated with the shared session.

In step 1405, the anchor node verifies, based on the security challengeprovided by the serving node and the cryptographic keying materialassociated with the shared session, the UE-generated challenge responseprovided by the UE.

If the challenge response is determined to not be valid by theverification of step 1405, in step 1410 the anchor node can discard thereceived PDU and terminate the current procedure.

If the challenge response is determined to be valid by the verificationof step 1405, and if the UE has been configured with a valid range ofPDCP sequence numbers for this LCID, in step 1415 the anchor node canoptionally verify that the PDCP sequence number is valid (e.g. is withinthe allowed range for the LCID).

If the PDCP sequence number is determined to not be valid in step 1415,in step 1420 the anchor node can discard the received PDU and terminatesthe current procedure.

If the PDCP sequence is verified, or if the verification of PDCPsequence is not performed, and the UE has been configured for user planeencryption (for this LCID), in step 1425 the anchor node decrypts thePDCP data (see FIG. 14B) using the configured cryptographic parametersand a COUNT computed from (or otherwise associated with) the PDCPsequence number received with the PDU.

If the UE has been configured to include a message integrity check (forthis LCID), in step 1430 the anchor node (optionally) performs averification of whether a message integrity check has been included (seeFIG. 14C) and that it is valid. If the message integrity check fails, instep 1435 the anchor node can discard the received PDU and terminate thecurrent procedure.

Subsequent to the verification of the message integrity in step 1430, orif the verification is not performed subsequent to the decryption of thePDCP data, the anchor node reconstructs the data packet in step 1440and, if the reconstructed data packet is valid, in step 1445 the anchornode transmits the reconstructed data packet to upper layers forforwarding to a remote corresponding node via the CN (i.e. in-orderdelivery of PDCP PDUs is always disabled for shared session LCIDs). Insome embodiments, the transmission of the reconstructed data packet maybe performed immediately. If the reconstructed data packet is not valid,in step 1450 the anchor node discards the received PDU and terminatesthe current procedure.

FIG. 14B illustrates an example of an embodiment of a PDCP data PDU 1455without message integrity check. FIG. 14C illustrates an example of anembodiment of a PDCP Data PDU 1460 further including a message integritycheck field 1465. The PDCP sequence number field 1457 can be used tocontain a sequence number that has been chosen (randomly) by the UEbased, for example, on a [min, max] range previously provided by theanchor node during RRC configuration.

In some embodiments, the UE may request confirmation from the anchornode that the PDU was successfully received and processed by the networkby setting a poll flag 1459 (e.g. P_(PDCP)) in the PDCP PDU header(FIGS. 14B & 14C). If the anchor node reconstructed a valid data packetin step 1440, and if the UE requests confirmation (e.g. P_(PDCP)=1), theanchor node may be operative to construct a PDCP status PDU, and totransmit the PDCP status PDU towards the UE, for instance via theserving node. The PDCP status PDU indicating which PDCP data PDUs havebeen successfully received and reconstructed by the anchor node.

In some embodiments, if the PDU received by the anchor node includes anSDAP data PDU header, the anchor node can use the QoS flow identifierassociated with the user plane PDU for subsequent SDAP operations (e.g.for applying a QoS mark to the NG-U packet transmitted to the CN UPGW).

Downlink Transmission Operations

Embodiments of procedures for downlink data transmissions using a sharedsession will be discussed in more detail.

Downlink data transmission in the inactive mode requires processing at aserving node to send a paging notification to the target UE(s) and, if apage response is received, to validate the responding UE(s) beforedelivering the downlink data over the radio link to the validated UE(s).Construction of the upper layer downlink PDU and ciphering of the PDUdata is performed by the anchor node before delivery of the downlink PDUto the serving node.

When an anchor node receives a downlink user data packet and determinesthat an inactive mode delivery should be attempted, the anchor node maybe operative to construct a downlink data plane PDU and to transmit thedownlink data plane PDU to a set of target nodes within the RANnotification area assigned to the UE session group. Similarly, if theanchor node determines that the configuration of the UE should beupdated while the UE is in an inactive mode, the anchor node may beoperative to construct a control plane PDU (e.g. an RRC message) and toforward the control plane PDU to the set of target nodes within the RANnotification area assigned to the UE session group. The term downlinkPDU is used herein to describe both data plane PDUs and control planePDUs. In some embodiments, the downlink PDU may include upper layer 2(e.g. PDCP and SDAP) protocol headers.

As described above, validation of the UE is performed using groupcryptographic keys that are known to all UEs assigned to the group or tothe shared session. To prevent replay attacks, a target UE can bevalidated using a challenge/response mechanism in which the anchor nodeprovides the serving node with both a security challenge and an expectedchallenge response. The security challenge is transmitted to the UE bythe serving node prior to transmission of the downlink PDU to the UE. Inorder to receive the downlink PDU, the UE must use the securitychallenge to generate a challenge response, and transmit theUE-generated challenge response to the serving node. The UE-generatedchallenge response is then validated by the serving node by comparingthe UE-generated challenge response to the expected challenge responsereceived from the anchor node. Downlink transmission of the datat canthen only be attempted by the serving node if the UE provides a validchallenge response to the security challenge. In some cases, thechallenge/response mechanism may require an additional step as comparedwith a basic inactive mode downlink transmission procedure withoutchallenge/response.

If requested, at least one of the target and serving nodes report theirdelivery status to the anchor node. If no page response is received by atarget node, the target node discards the downlink PDU. If the anchornode did not request a delivery status report from the target node(s) inthe event paging was unsuccessful, the target node takes no furtheraction. If the anchor node requested a delivery status report from thetarget node(s) in the event paging was unsuccessful, the target nodetransmits a delivery status report to the anchor node indicating pagingfailure.

If a target UE responds to the page, but fails to provide a validchallenge response to the serving node, the serving node may beoperative to transmit to the anchor node a delivery status reportindicating an unsuccessful delivery attempt (and optionally indicate thefailed challenge/response as the reason for delivery failure). In someembodiments the serving node may be operative to transmit the deliverystatus report based on an instruction received from the anchor node.

If the downlink PDU is destined for a particular UE, only one of thetarget nodes will normally succeed and act as a serving node to transmitthe downlink PDU to the UE. Responsive to receiving confirmation ofsuccessful receipt of the downlink PDU from the UE, the serving nodetransmits a successful delivery acknowledgement to the anchor node.

If the downlink PDU is destined for a group of UEs, more than one of thetarget nodes may succeed and each will act as a serving node to transmitthe downlink PDU to the UEs. Responsive to receiving confirmation ofsuccessful receipt of the downlink PDU from the UEs, each serving nodemay send successful delivery acknowledgement(s) to the anchor node. Ifthe anchor node fails to receive a successful delivery acknowledgementfrom any of the target nodes, it may initiate a paging failure recoveryprocedure.

Downlink transmission from a serving node (i.e. a target node thatserves a responding UE) to the UE(s) only involves lower layer radiolink procedures (e.g. PHY, MAC and RLC). The upper layer procedures(e.g. PDCP, SDAP, session management) are provided by the anchor node.

The upper layer operations in the anchor node will now be discussed.

The shared session context maintained by the anchor node typicallyincludes at least one of the following information elements:

-   -   the cryptographic keying material currently associated with the        shared session (e.g. group cryptographic keys and algorithms);    -   session configuration information (e.g. QoS profiles with QoS        flow identifiers, UPGW information);    -   RRC configuration parameters; and,    -   the PDCP sequence number configuration currently associated with        each LCID.

Based on the session and RRC configuration information, the anchor nodeis operative to map a received downlink user data packet onto acorresponding data radio bearer (DRB). This DRB may, in turn, be used toidentify a particular RRC configuration and context. Similarly, adownlink RRC message may be mapped onto a signalling radio bearer (SRB)with a particular RRC configuration and context.

After mapping the received downlink data packet to the corresponding DRBor SRB, the anchor node is operative to construct a downlink PDU (e.g.see FIGS. 14B & 14C) using a valid PDCP sequence number for the selectedradio bearer (DRB or SRB).

When the target UE has been configured to expect a message integritycheck (for this LCID) in the downlink PDU, the anchor node may befurther operative to compute an integrity check value using the derivedCOUNT and the configured cryptographic parameters from the cryptographickeying material. The anchor node is then operative to append theintegrity check value to the downlink PDU (e.g. see FIG. 14C).

If the UE was configured for encrypted communications (for this LCID),the anchor node encrypts the downlink PDU using the COUNT input variablederived from the PDCP sequence number and the configured cryptographicparameters from the cryptographic keying material, as described above.

In some embodiments, the anchor node may set a poll request (e.g.P_(PDCP)=1) if the anchor node requires acknowledgement from the UE thatthe downlink PDU was successfully received and authenticated.

A group RAN notification area (RNA) 301 identifies where a group of UEsassociated with the shared session can receive service under the sharedsession. While within the group RNA, the UE may operate in an inactivemode. A UE of the group is provided with the assigned RNA beforeentering the inactive mode. In some embodiments, the UE may also beconfigured to transmit to a serving node a location report indicatingits location based on a trigger. The trigger may include, for instance,expiry of a timer, or a measured location based on UE mobilityinformation that is indicative that the UE has moved, or is likely tomove, outside of its assigned RNA.

After the anchor node has constructed a downlink PDU, the anchor nodeuses the RNA configuration and, optionally, available UE mobilityinformation to determine a set of target nodes encompassing one or morecells of the RNA. The downlink PDU is encapsulated in an Rn PDU fortransmission across the intra-RAN network. The anchor node transmits acopy of the Rn PDU to each target node of the set of target nodes. FIG.15 illustrates an embodiment of an Rn PDU 1500 that may include any orall of the following information elements:

-   -   A list of one or more intended recipients 1505 each of which may        include any or all of:        -   a target UE identifier (TID) 1510 to identify at least one            UE within the group of UEs associated with the shared            session that is to receive the downlink data;        -   a RAN paging identifier (pagingID) 1515 associated with at            least one UE that is to receive the downlink data, if            different from the TID; and,        -   a challenge/response 1520 including a security challenge            generated by the anchor node and the corresponding challenge            response expected from the targeted UE.    -   Alternatively, in some embodiments, in place of a list of one or        more intended recipients, a single intended group recipient may        be provided that may include any or all of:        -   A TID in the form of a group paging identifier            (groupPagingID) associated with a group of targeted UEs that            are to receive the downlink data. In some embodiments, a TID            1510 may be a UEID 700. In some embodiments, a TID 1510 may            be another identifier associated with a UE, or group of UEs,            such as a temporary mobile station identifier (TMSI).        -   A challenge/response including a security challenge            generated by the anchor node and the corresponding challenge            response expected from the each of the targeted UEs in the            group.    -   an optional discontinuous reception (DRX) configuration        parameter 1525 indicating configured opportunities for        transmission to UEs within the shared session that may be used        for delivery of the downlink PDU. If provided, these configured        downlink transmission opportunities are used rather than default        opportunities derived from the pagingID or TID.    -   the LCID 1540 associated with the DRB or SRB selected by the        anchor node for delivery of the downlink PDU.    -   a set of delivery options 1535 that may include one or more of        the following:        -   the identity of cells within the target node that comprise            (part of) the RNA associated with the shared session;        -   the RLC mode configured for the designated LCID (e.g.            assured mode or un-assured mode); and,        -   an indication of whether the target node should provide a            delivery status report to the anchor node for at least one            of a successful and an unsuccessful delivery attempt.    -   the upper layer data comprising a PDCP data PDU 1542 for        delivery to the UE including, for instance:        -   PDCP header 1545;        -   SDAP header 1550 (if required); and,        -   PDCP data 1555 comprising at least one of the encrypted and            authenticated upper layer packet.    -   optional MAC control elements 1530 which may include, for        example, a new UEID to be used with subsequent inactive mode        procedures.

The downlink operations at the serving node will now be described.

When the downlink Rn data PDU is received by a target node, the targetnode determines the next paging opportunity, either obtained directlyfrom the DRX configuration if provided by the anchor node, or derivedfrom a paging identifier or target UE identifier (TID) received from theanchor node. In either case, at the scheduled opportunity, the targetnode is operative to construct and broadcast a paging notification thatmay be addressed to the UE(s) identified by the paging identifier or TIDsupplied by the anchor node. If a group paging identifier was providedby the anchor node, the serving node broadcasts a single pagingnotification. If a list of intended UE recipients was provided by theanchor node, the serving node broadcasts a paging notification at thescheduled paging opportunity for each of the target UEs. In someembodiments, the paging notification may comprise the TID. In someembodiments the paging notification may be broadcast with a securitychallenge. In some embodiments, the security challenge may betransmitted in response to receiving a reply to the paging notificationfrom one or more responding UE(s).

In embodiments where the security challenge is transmitted in responseto receiving a reply to the paging notification, when a page response isreceived from a responding UE that includes a responding UE identifier(RID) that corresponds to one of the intended recipients provided by theanchor node, the now-serving node (i.e. a target node that receives aresponse to its paging notification) initiates validation of theresponding UE by transmitting the security challenge received from theanchor node to the responding UE. The responding UE will then transmit achallenge response in a subsequent uplink transmission.

In embodiments, where the security challenge is transmitted with thepaging notification, a responding UE will include a responding UEidentifier (RID) and a challenge response when responding to the pagingnotification.

In these embodiments the serving node may evaluate the received RID toconfirm that it corresponds to a TID or paging identifier of an intendedrecipient identified by the anchor node. The evaluation may, forinstance, confirm that the RID is correctly associated with the TID orpaging identifier. The association may for instance, comprise a lookupby the serving node to confirm correspondence between the RID receivedform the responding UE and the TID received from the anchor node. Inother implementations, the evaluation may confirm that the RID matchesthe TID or paging identifier.

Upon to receiving a UE-generated challenge response from the respondingUE, the serving node evaluates the received challenge response toconfirm a match with the expected challenge response provided by theanchor node. If the received UE-generated challenge response matches theexpected challenge response, the responding UE is deemed to have beenvalidated by the serving node. The serving node is operative to transmitthe downlink PDU to the validated UE and, if requested, report thedelivery status to the anchor node.

If the received UE-generated challenge response does not match theexpected challenge response provided by the anchor node, the target nodeabandons the delivery attempt and, in some embodiments provides anunsuccessful delivery status report to the anchor node.

If no page response is received, the target node discards the downlinkPDU. Depending upon configuration by the anchor node, if the anchor nodedid not request a delivery status for unsuccessful paging no pagingstatus report is provided by the target node to the anchor node.Alternatively, if the anchor node requested a delivery status forunsuccessful paging, a delivery status report is provided by the targetnode to the anchor node indicating a failed paging.

Variations of inactive mode downlink transmission procedures may beprovided, several examples follow.

When a UE responds to a paging notification from one of the targetnodes, that target node is then deemed to be a serving node. FIG. 16A isa signaling diagram illustrating an embodiment of a downlinktransmission procedure between a serving node 1608 and a UE 1610. FIG.16A illustrates a “baseline” procedure 1600, generally characterized bythree (or optionally four) exchanges between the serving node 1608 andthe UE 1610.

In step 1615 the serving RAN 1608 transmits a paging notification to atleast one target UE in its coverage area. In some embodiments, thetransmission of the paging notification may take the form of a broadcasttransmission. The paging notification broadly includes a securitychallenge originally received from the anchor node as described above.

When a UE 1610 determines that it is identified in a received pagingnotification, the UE 1610 computes a challenge response using thereceived security challenge. In step 1617 the UE 1610 responds to thepaging message and security challenge by transmitting to the servingnode 1608 an identifier (RID) associated with the responding UE 1610 andthe UE-generated challenge response.

The serving node verifies the RID and the UE-generated challengeresponse and, if valid, in step 1619 transmits to the UE 1610 a downlinkPDU (i.e. in some embodiments the PDCP data PDU and, optionally, MACcontrol elements provided by the anchor node). The downlink PDU (e.g.rlcData) may be transmitted, for instance, using the RLC and MACprocedures of the serving node 1608. In some embodiments, HARQ may beused for recovery from transmission errors at the serving node 1608.

In an optional fourth stage, in step 1621 the UE 1610 transmits to theserving node 1608 an RLC status message (e.g. rlcStatus) in the form ofa delivery status report that confirms successful receipt of thedownlink PDU by the UE 1610. The execution of the optional fourth stagemay be performed when the UE 1610 has been configured to provide thedelivery status report. The UE 1610 may be configured, for instance, bythe serving node 1608, or the anchor node, transmitting to the UE 1610 arequest for acknowledgement, pre-configuration parameters in the UE1610, a radio bearer RLC configuration set for assured mode operation,or other configuration means.

In some embodiments, the downlink transmission procedure employed by theserving node 1608 for delivery of the downlink PDU depends on UEconfiguration signaled to the serving node 1608 by the anchor node. Thedifferent downlink transmission procedures modify the manner in whichthe UE 1610 receives the downlink transmission as described above withreference to FIG. 16A. For instance, in some embodiments the proceduremay include any or all of:

-   -   downlink transmission with paging and a conventional 4-step RA        procedure. This procedure may be used if a security challenge        can be accommodated within a conventional random access response        (RAR) transmitted by the serving node 1608.    -   downlink transmission with paging and a 5-step RA procedure.        This procedure may be used if a security challenge cannot be        accommodated within a random access response and must be        provided in a separate downlink transmission by the serving node        1608.    -   downlink transmission with paging and contention-free 4-step RA        procedure. This procedure may be used, along with a        contention-free RA procedure, to provide a security challenge in        a separate downlink transmission by the serving node 1608.

FIG. 16B is a signaling diagram illustrating an embodiment of acontention-based 4-step RA procedure 1601.

In optional step 1625 the serving node 1608 is operative to transmit tothe UE 1610 a downlink grant to initiate paging using a DCI encoded withthe pre-defined paging RNTI (P-RNTI). The timing of the downlink granttransmission may depend on a paging opportunity derived, for example,from the TID associated with the target UE 1610 or may be explicitlyprovided by the anchor node based on a pre-configured DRX cycle.

In step 1627 the serving node 1608 transmits to the UE 1610 a pagingnotification using the radio resources indicated in the downlink grant1625. The paging notification may be a paging message or otherindication of the UE 1610 (or group of UEs) being paged. For example, apaging message may contain a list of paging records each of whichidentifies one of the UEs 1610 or group of UEs being sought. In someimplementations, using the paging notification procedure may require anew PagingUE-Identity to be configured to incorporate inactive modetarget UE identifiers or other RNA-based paging identifiers. Forinstance:

PagingUE-Identity ::= CHOICE { s-TMSI S-TMSI, imsi IMSI,inactiveID InactiveIdentity, pagingID RNA-PagingIdentity,pagingGroupID PagingGroupIdentity,  ... } InactiveIdentity ::= BITSTRING (SIZE(pagingIdentitySize)) RNA-PagingIdentity ::= BIT STRING(SIZE(pagingIdentitySize)) PagingGroupIdentity ::= BIT STRING(SIZE(pagingIdentitySize))

Responsive to the paging notification transmitted in 1627, if arecipient UE 1610 determines that the identifying component in thepaging notification corresponds to one of the identifiers assigned tothat UE (i.e. a TID or paging identifier), the UE 1610 conventionallyinitiates a random access procedure by selecting a random accesspreamble (in some embodiments the selection may be arbitrary) and instep 1629 transmits the preamble to the serving node 1608 in a scheduledphysical random access channel (PRACH). Other UEs in the group may haveindependently selected the same preamble for transmission in the PRACH.

In optional step 1631 the serving node 1608 transmits, to the UE 1610, adownlink grant using a DCI encoded with a predefined random access RNTI(RA-RNTI) that points to (or otherwise indicates) a region in the PDSCHthat contains a random access response (RAR).

In step 1632, based on the downlink grant, the serving node 1608transmits a RAR to the UE 1610. The RAR contains a list of random accesspreamble identifiers (RAPIDs) corresponding to the preambles detected bythe serving node 1608 in the PRACH. For each RAPID, the serving node1608 is operative to provide any or all of:

-   -   a temporary C-RNTI assignment that can be used by the UE 1610 as        the ephemeral C-RNTI (eC-RNTI);    -   a security challenge, as received by the serving node 1608 from        the anchor node; and,    -   an uplink grant that may be used by the UE 1610 to transmit to        the serving node 1608 the UE's identifier and a challenge        response to the security challenge.

After receiving the security challenge, the UE 1610 can compute aUE-generated challenge response using the received security challenge,as described above.

In step 1635, using the received uplink grant, the UE 1610 transmits tothe serving node 1608 a responding UE identifier (RID) associated withthe PagingUE-Identity in one MAC control element and the UE-generatedchallenge response in a second MAC control element. In some embodiments,no other information (e.g. an RRC message) is required in this uplinktransmission which may be beneficial from the perspective of minimizingsignaling.

If the serving node 1608 successfully receives the uplink transmission1635 from the UE 1610 (i.e. the CRC included in the receivedtransmission block is valid), the serving node 1608 may be operative toconfirm either or both of:

-   -   the RID indicated in step 1635 corresponds to a TID associated        with an intended recipient previously received from the anchor        node; and,    -   the UE-generated challenge response received in step 1635        matches the expected challenge response previously received from        the anchor node.

If both the RID and challenge response are valid, in optional step 1637the serving node 1608 transmits a downlink grant to the UE 1610. Thistransmission of the downlink grant may be performed using a DCI encodedwith the eC-RNTI assigned to the UE 1610 in step 1632.

If the serving node 1608 does not receive a response from the target UE(e.g. the UE may not be within the coverage area of the node), servingnode 1608 may repeat the paging procedure or abandon the deliveryattempt. As explained above, the serving node 1608 (which may bereferred to as a target node because a failed delivery attempt resultsin the target node never actually serving the UE) may abandon thedelivery attempt. Depending on configuration and implementation, theabandonment of the delivery attempt may be done either with or withoutreporting a failed attempt back to the anchor node.

Following transmission of the downlink grant in optional step 1637, instep 1639 the serving node 1608 transmits to the UE 1610 a downlinktransmission based on the downlink grant. The downlink transmission caninclude a received UE identifier, such as the RID received by theserving node 1608 in step 1635, and the downlink PDU encapsulated withan RLC header (e.g. rlcData).

After receiving the downlink transmission corresponding to the downlinkgrant received in step 1637, the UE 1610 can compare the received UEidentifier contained in the contention resolution identity MAC CE of thereceived downlink transmission 1639 against its own identifier (i.e. theRID that the UE 1610 transmitted in step 1635). In response to thecomparison of the received identifier with the UE's own identifier:

-   -   If the received UE identifier corresponds to the UE's RID,        downlink reception of the downlink PDU is deemed successful.    -   If the received UE identifier does not match the UE's RID,        downlink reception of the downlink PDU is deemed unsuccessful        (for instance, another UE may have transmitted the same preamble        in step 1629 and the serving node 1608 did not receive the RID        from UE 1610). Depending upon configuration, the UE 1610 may        attempt to respond to the paging notification by repeating this        procedure, starting at step 1629, at a later time.

In embodiments where the serving node 1608 requested an RLCacknowledgement in step 1639, or if the radio bearer RLC is configuredfor assured mode operation, in optional step 1641 the serving node 1608transmits to the UE 1610 a DCI containing an uplink grant encoded withthe eC-RNTI assigned to the UE 1610

After receiving the DCI (and possibly in response to the receipt of theDCI), and using the uplink grant received in step 1641, in step 1643 theUE 1610 transmits a status report (e.g. rlcStatus) to the serving node1608. The transmitted status report may confirm successful downlinkreception of the RLC data PDU. In some embodiments, the UE 1610 mayfurther be operative to use the uplink grant received in step 1641 totransmit a status report indicating downlink reception failure.

FIG. 16C is a signaling diagram illustrating an embodiment of acontention-based 5-step RA procedure 1602. The 5-step RA procedure maybe used in a variety of situations including where a security challengecannot be accommodated within a RAR and must be provided in a separatedownlink transmission.

The 5-step RA procedure 1602 of FIG. 16C generally follows the abovesteps described for the 4-step RA procedure 1601 of FIG. 16B, with theexception that step 1632 is replaced with steps 1633 and 1634. In placeof the RAR transmitted in step 1632, in step 1633 the serving node 1608transmits a RAR that contains a list of random access preambleidentifiers (RAPIDs) corresponding to the preambles detected by theserving node in the PRACH. For each RAPID, the serving node provides atleast one of:

-   -   a temporary C-RNTI assignment that will be used by the UE as the        ephemeral C-RNTI (eC-RNTI); and,    -   a downlink grant that can be used by the serving node 1608 to        transmit the security challenge. This differs from the 4-step RA        procedure RAR that includes an uplink grant and the security        challenge, and not a downlink grant.

In step 1634, using the downlink grant transmitted in step 1633, theserving node 1608 transmits to the UE 1610 a downlink message. Thedownlink message may be tyransmitted in the downlink grant of step 1633.In some embodiments, the downlink grant can include at least one of:

-   -   the security challenge received from the anchor node; and,    -   an uplink grant that may be used by the UE 1610 to transmit its        identity and a response to the security challenge.

FIG. 16D is a signaling diagram illustrating an embodiment of acontention-free 4-step RA procedure 1603.

In optional step 1650 the serving node 1608 transmits to the UE 1610 adownlink grant to initiate paging using a DCI encoded with thepre-defined paging RNTI (P-RNTI). The timing of the downlink grant maydepend on a paging opportunity derived, for example, from the TIDassociated with the target UE, or may be explicitly provided by theanchor node based on a pre-configured DRX cycle.

In step 1652 the serving node 1608, using the radio resources indicatedin the downlink grant 1650, transmits to the UE 1610 a pagingnotification, such as a paging message or other indication of the UE1610 being paged. For example, a paging message may contain a list ofpaging records each of which identifies one of the UEs being paged. Insome implementations, using the paging notification procedure mayrequire a new PagingUE-Identity to be configured to incorporate inactivemode target UE identifiers or other RNA-based paging identifiers. Forinstance:

PagingUE-Identity ::= CHOICE { s-TMSI S-TMSI, imsi IMSI,inactiveID InactiveIdentity, pagingID RNA-PagingIdentity,  ... }InactiveIdentity ::= BIT STRING (SIZE(pagingIdentitySize))RNA-PagingIdentity ::= BIT STRING (SIZE(pagingIdentitySize))

The paging record can include a dedicated preamble to be used by the UEin a subsequent random access transmission and may contain an ephemeralC-RNTI (eC-RNTI) that may be subsequently used to schedule transmissionsbetween the UE and serving node, for instance:

PagingRecord :: SEQUENCE { ue-Identity PagingUE-Identity,cfPreamble RACH-ConfigDedicated OPTIONAL, ecRNTI C-RNTI OPTIONAL,  ... }

Each paging record identifies an individual UE 1610. Accordingly, agroup paging identifier, as used above for contention RA procedures,cannot be used with the contention-free RA procedure.

Responsive to a UE 1610 determining that the indication in the pagingnotification corresponds to an identifier assigned to the UE 1610 (e.g.a TID or paging identifier), in step 1654 the UE 1610 transmits thededicated preamble to acknowledge receipt of the paging notification andto initiate a conventional contention-free RA procedure. Thiscontention-free RA procedure can be based on the preamble defined in thededicated RACH configuration (e.g. RACH-ConfigDedicated) of the matchedpaging notification.

Responsive to receiving the dedicated preamble sent by the UE 1610 instep 1654, in optional step 1656 the serving node 1608 transmits to theUE 1610 a downlink grant using a downlink DCI encoded with the eC-RNTIassigned to the UE 1610 in the matched paging record.

If the serving node 1608 does not receive a response 1654 from thetarget UE 1610 (for any of a number of reasons including that the UE1610 may be outside the coverage area of the serving node 1608 when thepage is transmitted), in some implementations the serving node 1680 mayrepeat the paging procedure. In some embodiments, the serving node 1608may abandon the delivery attempt (either with or without reporting tothe anchor node) after a number of attempts.

In step 1658, based on the downlink grant 1656, the serving node 1608transmits a downlink message to the UE 1610. The downlink message mayinclude at least one of:

-   -   a security challenge as received by the serving node 1608 from        the anchor node; and,    -   an uplink grant that may be used by the UE 1610 to transmit to        the serving node 1608 the UE's identifier and a challenge        response to the security challenge.

After receiving the security challenge, the UE 1610 computes aUE-generated challenge response using the received security challenge asdescribed above.

In step 1660, using the uplink grant received in 1658, the UE 1610transmits a responding UE identifier (RID) to the serving node 1608. Thetransmitted RID is typically associated with the PagingUE-Identity inone MAC control element and the UE-generated challenge response in asecond MAC control element. In some embodiments, no other information(e.g. an RRC message) is required in this uplink transmission which mayprovide a benefit from the perspective of reduced signaling.

Upon successful reception of the uplink transmission 1660 from the UE1610 (i.e. the CRC included in the received transmission block isvalid), the serving node 1608 may be operative to confirm at least oneof:

-   -   the RID indicated in step 1660 corresponds to a TID associated        with an intended recipient previously received from the anchor        node; and,    -   the UE-generated challenge response received in step 1660        matches the expected challenge response previously received from        the anchor node.

If both the RID and challenge response are valid, in optional step 1662the serving node 1608 transmits to the UE 1610 a downlink grant using aDCI encoded with the eC-RNTI assigned to the UE 1610 in step 1652.

If the serving node 1608 does not receive a response 1660 from thetarget UE (e.g. the UE may not be within the coverage area of theserving node), it may repeat the paging procedure or abandon thedelivery attempt. As explained above, the serving node 1608 (which maybe referred to as a target node since it failed the delivery attempt)may abandon the delivery attempt either with or without reporting afailed attempt back to the anchor node, depending upon theimplementation.

Following transmission of the downlink grant in step 1662, in step 1664the serving node 1608 transmits to the UE 1610 a downlink transmissionbased on the downlink grant. The downlink transmission including areceived UE identifier, such as the RID received in step 1660, and thedownlink PDU encapsulated with an RLC header (e.g. rlcData).

Responsive to receiving the downlink transmission corresponding to thedownlink grant received in step 1662, the UE 1610 compares the receivedUE identifier contained in the contention resolution identity MAC CE ofthe received downlink transmission 1664 against its own UE identifier(i.e. the RID transmitted in step 1660):

-   -   If the received UE identifier corresponds to the UE's RID,        downlink reception of the RLC data PDU is deemed successful.    -   If the received UE identifier does not match the UE's RID,        downlink reception of the RLC data PDU is deemed unsuccessful.        Depending upon configuration, the UE 1610 may attempt to respond        to the paging notification by repeating this procedure, starting        at step 1654, at a later time.

In embodiments where the serving node 1608 requested an RLCacknowledgement in step 1664, or if the radio bearer RLC is configuredfor assured mode operation, in optional step 1666 the serving node 1608transmits to the UE 1610 a DCI containing an uplink grant encoded withthe eC-RNTI assigned to the UE 1610

Responsive to receiving the DCI, and using the uplink grant received instep 1666, in step 1668 the UE 1610 transmits to the serving node 1608 astatus report (e.g. rlcStatus) confirming successful downlink receptionof the RLC data PDU. In some embodiments, the UE 1610 may further beoperative to use the uplink grant received in step 1666 to transmit astatus report indicating downlink reception failure.

The challenge response transmitted by the UE 1610 in step 1617 of FIG.16A may comprise a MAC control element containing a RID and a MACcontrol element containing the challenge response, such as theembodiment as shown in FIG. 17. In other embodiments, one or more of theRID and challenge response may be included as information elements inanother Uu protocol such as RLC, PDCP or RRC.

In the embodiment of FIG. 17, the MAC control element (CE) 1701 includesat least the following fields:

-   -   a MAC element header 1705 indicating that it is a Control        Element (CE) of type “sessionID_t”, where “sessionID_t” is a        predefined value; and,    -   a RID 1710 assigned to a UE 1610; this may be a UEID as        described in FIG. 7 for example or some other identifier        associated with the UE 1610.

When a serving node is transmitting a paging notification at a group ofUEs (e.g. by including a PagingGroupIdentity in the pagingnotification), the RID can be an identifier associated with anindividual target UE 1610 from the group. In other cases, the RID can bethe same identifier included in the paging notification. It may, howeverbe a different identifier associated with the UE 1610 and the sharedsession and provided to both the UE 1610 and the serving node 1608 bythe anchor node.

The MAC CE 1702 includes at least the following fields:

-   -   a MAC element header 1720 indicating that it is Control element        of type “response_t”, where “response_t” is a predefined value;        and,    -   the UE-generated challenge response 1730 computed by the UE        1610.

FIG. 18 illustrates an embodiment of a downlink MAC PDU for transmissionby a serving node to a UE. The downlink MAC PDU 1800 includes a MAC dataelement 1803 containing the downlink PDCP PDU, and in some embodimentsmay include one or more serving node MAC control element 1801 and zeroor more anchor node MAC control CEs 1802.

The serving node 1608 may also provide one or more serving node MACcontrol elements 1801. Each MAC CE 1801 including a serving node header1805 and serving node MAC CE contents 1810.

In an embodiment, the downlink MAC PDU 1800 includes a serving node MACcontrol element 1801 comprising a contention resolution MAC CE. Thecontention resolution MAC CE contents 1810 will typically contain atleast the RID provided by the UE 1601 in step 1617.

In some embodiments, additional serving node MAC control elements 1801may be provided as required for UE operation at the serving node 1608(e.g. for assignment of a new eC-RNTI, for timing advancement, for powercontrol, etc).

In some embodiments, the downlink MAC PDU 1800 may include zero or moreanchor node MAC control CEs 1802 each made up of a control header 1815and control MAC CE contents 1820. Inclusion of the anchor node MACcontrol CEs 1802 being dependent on whether such were provided by theanchor node to the serving node in the downlink Rn PDU. These MAC CEs(e.g. containing a new UEID 700 for use as an inactive mode identifier)may also be included by the serving node 1608 in the downlink MAC PDU1800.

The downlink data is contained in a MAC data element 1803 that mayinclude one or more of the following fields:

-   -   a MAC element header 1825 indicating that this is a Data        element; this field also includes the logical channel identifier        (LCID) provided by the anchor node;    -   a length field 1830 indicating the size of the MAC data element        (e.g. the number of octets);    -   a Radio Link Control (RLC) header 1835 constructed by the        serving node; and    -   the Packet Data Convergence Protocol (PDCP) PDU 1860 provided by        the anchor node.

Asynchronous HARQ may be used for recovery from transmission errorsfollowing the assignment of an eC-RNTI to the UE 1610 by the servingnode 1608.

RLC procedures may be used to transmit a downlink PDCP PDU that must besegmented across multiple transport blocks. These RLC procedures makeuse of the eC-RNTI assigned to the UE 1610 by the serving node 1608 foruplink and downlink transmission grants.

In some embodiments the anchor node may include a delivery status optionin the Rn PDU indicating whether the target node should provide adelivery status report to the anchor node. In some embodiments, adelivery status report may be requested by the anchor node to indicatebetween a variety of outcomes including one or more of the following:

-   -   successful delivery, indicating that the PDCP PDU was        successfully delivered by the serving node to the UE using an        assured mode (AM) procedure. Note, however, in this embodiment        this delivery status report does not indicate successful        processing of the received PDCP PDU by the UE. Successful        processing of the received PDCP PDU by the UE may be indicated        by a separate PDCP status report from the UE.    -   unsuccessful delivery (no page response received), indicating        that the UE did not respond to a paging notification initiated        by the target node. This may be used. for example, by the anchor        node to ensure delivery of, and attempted action on, a paging        request transmitted to a target node.    -   unsuccessful delivery (page response received), indicating that        the UE did respond to a paging notification initiated by the        target node but a subsequent assured mode (AM) attempt to        transmit the downlink PDU to the UE failed. This may be used,        for example, by the anchor node to determine the reachability of        a UE even if the UE is moving or is operating in a region with        poor coverage.    -   delivery attempted (page response received), indicating that the        UE did respond to a paging notification initiated by the target        node and that a subsequent un-assured mode (UM) attempt to        transmit the downlink PDU to the UE was completed. This may be        used, for example, by the anchor node to determine the        reachability of a UE when delivering UM data.    -   unsuccessful delivery (invalid challenge response), indicating        that a UE did respond to a paging notification initiated by the        target node but the UE either failed to provide a challenge        response to the security challenge or provided an invalid        challenge response to the security challenge.

If the delivery status outcome report requested by the anchor nodematches the delivery results at the target node, the target nodeconstructs a delivery status PDU and transmits it to the anchor node inan Rn PDU.

FIG. 19 illustrates an embodiment of an Rn delivery status PDU 1900. Theillustrated delivery status PDU 1900 includes at least a UE identifier(e.g. TID) 1905, an indication of the delivery status outcome 1915, andoptionally a UE paging identifier (e.g. pagingID or groupPagingID) 1910.

In some embodiments, the anchor node may be embodied as an anchor NF.The anchor node NF may be a dedicated network element that providesanchor node functionality, or a virtualized entity representing a sliceof such an element. In other embodiments, the anchor node NF may be aVNF created by the execution of software within a data center or othersuch computing environment. In general, in this embodiment operationsperformed by the anchor node described above are performed by the groupanchor NF in the CN-based anchor node model. Serving nodes performsimilar operations in both the RAN- and CN-based anchor node models,some differences are described below.

Referring to FIG. 20, a group anchor NF 2005 maintains the connectionsto other core network functions 2007 for the shared session. The groupanchor NF 2005 also maintains, or has access to, the currentconfiguration and other context information 2009 associated with theshared session. The group anchor NF 2005 performs equivalent functionsto the group anchor node 302 described above. In some embodiments, thegroup anchor NF 2005 may be incorporated into, or co-located with, theCN UPGW associated with the shared session. The main differences betweenthe group anchor NF 2005 and the anchor node described above is in theprotocol stack, and in some embodiments the encryption procedure.

A group tracking area (GTA) 2015 denotes (the cells of) the targetserving nodes 2010 where UEs within the shared session can receiveservice while roaming within the public land mobile network (PLMN). Thescope of the GTA 2015 may be as small as a single cell or as large asthe entire PLMN. A UE that roams outside the designated GTA 2015, isoperative to notify the group anchor NF 2005 of its departure from theGTA 2015 and may be assigned to at least one of a different sharedsession and a different group anchor NF 2005. The GTA 2015 is equivalentto a group RAN notification area 301 described above.

The group anchor NF 2005 may be connected via an intra-PLMN backhaulnetwork to the one or more target serving nodes 2010 within the PLMN.Each of the one or more target serving nodes 2010 may control one ormore cells associated with the GTA 2015 of the shared session. Theinterface between the group anchor NF 2005 and the one or more targetserving nodes 2010, dubbed Sn in FIG. 20, may be similar to an NGinterface, an S1 interface, an X2 interface, an Xn interface, a CU-DUinterface, or other suitable interface.

In general, operations performed by the group anchor node 302 areperformed by the group anchor NF 2005 in the CN-based anchor node model.Target nodes 2010 perform similar operations in both the RAN- andCN-based anchor node models. Some particular differences are describedbelow.

In a CN-based anchor node model, the network side of the Uu protocolstack (including PDCP and SDAP) is completely contained within a servingnode 2010. The PDCP procedures in the target serving nodes 2010,however, may be disabled for the shared session—e.g. PDCP user planeencryption and integrity protection may be explicitly disabled or a NULLcryptographic algorithm may be selected. In some embodiments, in placeof the PDCP user plane security, non-access stratum (NAS) securityprocedures are provided by the group anchor NF 2005 using NAS encryptionand integrity protection keys and algorithms. Similarly, within the UE,PDCP procedures are effectively disabled and NAS cryptographic keys andalgorithms may be used for user plane data protection. It should beunderstood that from the perspective of the anchor function, there is nodifference between an implementation in which the protocol stack shownin the target serving nodes 2010 is split or if it is handled in asingle node.

For uplink traffic, once a serving node 2010 has successfully received acomplete uplink PDCP PDU, the enclosed NAS user plane PDU is forwardedto the group anchor NF 2005 identified by the anchor node 710 in theUEID 700. The packet used to transfer the PDU over the Sn interfacebetween the serving node 2010 and group anchor NF 2005 may include anyor all of the following:

-   -   a UE reference, comprising at least the RID 1710 as received        from the UE;    -   the security challenge issued by the serving node 2010 and the        UE-generated challenge response provided by the UE; and,    -   the cryptographically-protected NAS user plane PDU received from        the UE, including the user data for forwarding to a remote        corresponding node.

For downlink traffic, when the group anchor NF 2005 has constructed acryptographically-protected NAS user plane PDU, it can use the GTAconfiguration and, optionally, available UE mobility information todetermine a set of target nodes from the group target serving nodes 2010encompassing one or more cells of the GTA 2015 and then sends a copy ofthe NAS user plane PDU to each of the target nodes. The NAS user planePDU is encapsulated in an Sn PDU that may include at least one of thefollowing information elements:

-   -   A list of one or more intended recipients each of which may        include:        -   a target UE identifier (TID) associated with a UE that is to            receive the downlink data;        -   a paging identifier (pagingID) associated with a UE that is            to receive the downlink data, if different from the TID;            and,        -   a security challenge generated by the group anchor NF 2005            and the corresponding challenge response expected from the            targeted UE.    -   Alternatively, a single intended recipient may be provided that        includes a groupPagingID associated with a group of targeted        UEs.    -   An optional DRX configuration indicating configured        opportunities for transmission to UEs within the shared session        that may be used for delivery of the downlink PDU. If provided,        these configured downlink transmission opportunities are used        rather the default opportunities derived from the pagingID or        TID.    -   A set of delivery options that may include one or more of the        following:        -   the identity of cells or RAN notification areas within the            target node that comprise (part of) the GTA 2015 associated            with the UE session group; and,        -   an indication of whether a target node should provide a            delivery status report to the group anchor NF for at least            one of a successful and an unsuccessful delivery attempt.    -   The NAS user plane PDU for delivery to the UE, including at        least one of the encrypted upper layer packet and integrity        protected upper layer packet.

FIG. 21A is a block diagram of an electronic device (ED) 52 illustratedwithin a computing and communications environment 50 that may be usedfor implementing the devices and methods disclosed herein. In someembodiments, the electronic device may be an element of communicationsnetwork infrastructure, such as a base station (for example a NodeB, anenhanced Node B (eNodeB), a next generation NodeB (sometimes referred toas a gNodeB or gNB), or various other nodes or functions within a radioaccess and core network. In other embodiments, the electronic device maybe a device that connects to network infrastructure over a radiointerface, such as a mobile phone, smart phone or other such device thatmay be classified as a User Equipment (UE). In some embodiments, ED 52may be a Machine Type Communications (MTC) device (also referred to as amachine-to-machine (m2m) device), or another such device that may becategorized as a UE despite not providing a direct service to a user. Insome references, an ED may also be referred to as a mobile device, aterm intended to reflect devices that connect to mobile network,regardless of whether the device itself is designed for, or capable of,mobility. Specific devices may utilize all of the components shown oronly a subset of the components, and levels of integration may vary fromdevice to device. Furthermore, a device may contain multiple instancesof a component, such as multiple processors, memories, transmitters,receivers, etc. The electronic device 52 typically includes a processor54, such as a Central Processing Unit (CPU), and may further includespecialized processors such as a Graphics Processing Unit (GPU) or aDigital Signal Processor (DSP) or other such processor, a memory 56, anetwork interface 58 and a bus 60 to connect the components of ED 52. ED52 may optionally also include components such as a mass storage device62, a video adapter 64, and an I/O interface 68 (shown in dashed lines).

The memory 56 may comprise any type of non-transitory system memory,readable by the processor 54, such as static random access memory(SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM),read-only memory (ROM), or a combination thereof. In an embodiment, thememory 56 may include more than one type of memory, such as ROM for useat boot-up, and DRAM for program and data storage for use whileexecuting programs. The bus 60 may be one or more of any type of severalbus architectures including a memory bus or memory controller, aperipheral bus, or a video bus.

The electronic device 52 may also include one or more network interfaces58, which may include at least one of a wired network interface and awireless network interface. As illustrated in FIG. 1A, network interface58 may include a wired network interface to connect to a network 74, andalso may include a radio access network interface 72 for connecting toother devices over a radio link. When ED 52 is network infrastructure,the radio access network interface 72 may be omitted for nodes orfunctions acting as elements of the Core Network (CN) other than thoseat the radio edge (e.g. an eNB or gNB). When ED 52 is infrastructure atthe radio edge of a network, both wired and wireless network interfacesmay be included. When ED 52 is a wirelessly connected device, such as aUser Equipment, radio access network interface 72 may be present and itmay be supplemented by other wireless interfaces such as WiFi networkinterfaces. The network interfaces 58 allow the electronic device 52 tocommunicate with remote entities such as those connected to network 74.

The mass storage 62 may comprise any type of non-transitory storagedevice configured to store data, programs, and other information and tomake the data, programs, and other information accessible via the bus60. The mass storage 62 may comprise, for example, one or more of asolid state drive, hard disk drive, a magnetic disk drive, or an opticaldisk drive. In some embodiments, mass storage 62 may be remote to theelectronic device 52 and accessible through use of a network interfacesuch as interface 58. In the illustrated embodiment, mass storage 62 isdistinct from memory 56 where it is included, and may generally performstorage tasks compatible with higher latency, but may generally providelesser or no volatility. In some embodiments, mass storage 62 may beintegrated with a heterogeneous memory 56.

The optional video adapter 64 and the I/O interface 68 (shown in dashedlines) provide interfaces to couple the electronic device 52 to externalinput and output devices. Examples of input and output devices include adisplay 66 coupled to the video adapter 64 and an I/O device 70 such asa touch-screen coupled to the I/O interface 68. Other devices may becoupled to the electronic device 52, and additional or fewer interfacesmay be utilized. For example, a serial interface such as UniversalSerial Bus (USB) (not shown) may be used to provide an interface for anexternal device. Those skilled in the art will appreciate that inembodiments in which ED 52 is part of a data center, I/O interface 68and Video Adapter 64 may be virtualized and provided through networkinterface 58.

In some embodiments, electronic device 52 may be a standalone device,while in other embodiments electronic device 52 may be resident within adata center. A data center, as will be understood in the art, is acollection of computing resources (typically in the form of servers)that can be used as a collective computing and storage resource. Withina data center, a plurality of servers can be connected together toprovide a computing resource pool upon which virtualized entities can beinstantiated. Data centers can be interconnected with each other to formnetworks consisting of pools computing and storage resources connectedto each by connectivity resources. The connectivity resources may takethe form of physical connections such as Ethernet or opticalcommunications links, and in some instances may include wirelesscommunication channels as well. It should be understood that any or allof the computing, storage and connectivity resources (along with otherresources within the network) can be divided between differentsub-networks, in some cases in the form of a resource slice. If theresources across a number of connected data centers or other collectionof nodes are sliced, different network slices can be created.

FIG. 21B illustrates a system 160 in which a core/RAN network 162provides radio access and core network services to electronic devicessuch as UE1 164 and UE2 166. In FIG. 1B, network functions areinstantiated upon the underlying resources of a data center. Thefunctions are shown as being exploded out of the pool of resources uponwhich they are instantiated. This is done to indicate that the functionsact as independent entities and from a logical perspective they areindistinguishable from a physical node carrying out the same function.It should also be understood that in a sliced network where data centersprovide the underlying resources upon which the slices are created, itis possible for a single network to have slices that support differentversions of networks, so for example, in addition to having avirtualized network to support 5G traffic, a separate network slice canbe created to support 4G networks. Traffic from electronic devices canbe routed through network functions, to a gateway 168 that providesaccess to a packet data network 170 such as the Internet. Radio accessservices are typically provided by a RAN, which in the embodimentillustrated in FIG. 1B is provided as a Cloud-RAN (C-RAN). Where aconventional RAN architecture was designed to be composed of discreteelements, such as eNodeBs, that were connected to the Core Networkthrough a backhaul network, a C-RAN takes advantage of functionvirtualization to virtualize the Access Nodes of the network. Much as aphysical Access Node, such as an eNodeB, was connected to an antenna bya front haul link, in the illustrated embodiment of a C-RAN AccessNodes, such as a gNodeB, are connected to antenna (or to a remote radiohead (RRH)) through a front haul connection, but are functions that areinstantiated upon compute resources in network 162. If a gNodeB isdivided into a Central Unit and a plurality of Distributed Units, thevirtualized Distributed Units may in some embodiments be instantiated ator near the location of the antenna or RRH, while a Centralized Unit maybe instantiated at a data center to connect and serve a plurality ofgeographically dispersed Distributed Units. For example, UE1 164 isconnected to the network through AN 172, which can provide radio accessservices through antenna 174. AN 172 is instantiated upon the computeand storage resources provided by a data center, in this case datacenter 198-1. Similarly, AN 176 and AN 180, which are connected to thesame set of antennae 178, are also instantiated upon the resources ofdata center 198-1. AN 180 provides radio access services to UE 2 166,which also makes use of the access services provided by AN 182. AN 182is connected to antenna 184, and is instantiated upon the resources ofdata center 198-2. AN 186 is connected to antenna 188, and is alsoinstantiated upon the resources of data center 198-2. It should beunderstood that the fronthaul connections linking the virtualized accessnodes to the antennas or RRHs, may be direct connections, or they mayform a fronthaul network. The integration of a CRAN into a core networkmay obviate or reduce the concerns associated with backhaul connectionsas the AN functions may be co-located with CN functions. As such, DataCenter 198-1 also serves as a location at which a user-specific gatewayfunction (u-GW) 190 is instantiated. This function is also instantiatedin data center 198-2. Having a function instantiated at more than onedata center may be part of a function migration process in which thefunction is moved through the network, or one of the instantiations maybe an intentionally redundant instantiation. Both functions can beinstantiated and configured, with only one of them active at a time, orthey may both be active, but only one of them may be transmitting datato the UE. In other embodiments, such as those focussed onUltra-Reliable connections, such as Ultra-Reliable Low LatencyCommunications (URLLC), both functions may be active and transmittingdata to (or receiving data from) an ED such as UE2 166. Networkfunctions such as a Home Subscriber Server (HSS) 192, an Access andMobility Management Function (AMF) 194 or its predecessor MobilityManagement Entity (MME), and a Network Exposure Function (NEF) 196 areshown as being instantiated on the resources of Data Center 198-5, 198-4and 198-3 respectively.

The virtualization of the network functions allows a function to belocated in the network at a location topologically close to the demandfor the service provided by the function. Thus, AN 172, which isassociated with antenna 174, can be instantiated upon data centerresources at the data center closest to the antenna 174, in this casedata center 198-1. Functions such as an NEF 196, which may not need tobe close to ANs, may be instantiated further away (in either or both ofa topological or physical sense). Thus, NEF 196 is instantiated at datacenter 198-3, and the HSS 192 and AMF 194 are instantiated at datacenters 198-5 and 198-4 respectively, which are topologically closer tothe radio edge of the network 162. In some network implementations, datacenters can be arranged hierarchically and different functions can beplaced at different levels in the hierarchy.

In some embodiments, systems, apparatus and methods are provided forhandling uplink communications between a group of one or more UserEquipment (UEs) and network nodes of a communication network as part ofa shared session.

In some embodiments, a method is provided for execution by an anchornode of a communication network. The method including the anchor node:receiving, from another network node, a shared session establishmentrequest; establishing a shared session context for a group of one ormore UEs; and transmitting, to the other network node, a shared sessionidentifier corresponding to the shared session context.

In some embodiments, a network function is provided. The networkfunction executing on a network node of a communication network to actas an anchor node, and the network node including: a network interfacefor receiving data from and transmitting data to network functionsconnected to a network; a processor; and a non-transient memory forstoring instructions that when executed by the processor cause thenetwork function to be configured to: receive, from another networknode, a shared session establishment request; establish a shared sessioncontext for a group of one or more UEs; and, transmit, to the othernetwork node, a shared session identifier corresponding to the sharedsession context.

In some embodiments, a network function is provided. The networkfunction executing on a network node of a communication network to actas a serving node, and the network node including: a network interfacefor receiving data from and transmitting data to network functionsconnected to a network; a processor; and a non-transient memory forstoring instructions that when executed by the processor cause thenetwork function to be configured to: receive, from a user equipment(UE), a UE identifier (UEID) comprising a shared session identifier fora group of one or more UEs and a UE identifying component thatidentifies the UE within the shared session; transmit, to the UE, asecurity challenge; receive, from the UE, a challenge response derivedfrom at least the security challenge and cryptographic keying materialassociated with the shared session; and, transmit, to an anchor nodeassociated with the shared session based on the shared sessionidentifier, the UEID, the security challenge, and the challengeresponse.

In some embodiments, a method is provided. The method including aserving node of a communication network: receiving, from a userequipment (UE), a UE identifier (UEID) comprising a shared sessionidentifier for a group of one or more UEs and a UE identifying componentthat identifies the UE within the shared session; transmitting asecurity challenge to the UE; receiving, from the UE, a challengeresponse derived from at least the security challenge and cryptographickeying material associated with the shared session; and, transmitting,to, an anchor node associated with the shared session the anchor nodebased on the shared session identifier, the UEID, the securitychallenge, and the challenge response.

In some implementations of the method, the serving node: receiving, fromthe UE, uplink data; and transmitting, to the anchor node, the uplinkdata.

In some implementations of the method, before the receiving the UEID,the method further includes the serving node: receiving, from the UE, anetwork attachment request; forwarding, to another network node of thecommunication network, the network attachment request; receiving, fromthe other network node, a shared session identifier; transmitting, tothe anchor node identified from the shared session identifier, theshared session identifier and a request for the shared session context;receiving, from the anchor node, the shared session context and a UEIDcomprising the shared session identifier; and transmitting, to the UE,the UEID.

In some implementations of the method, the other network node comprisesa control plane function executing on a network node of a radio accessnetwork or a core network of the communication network.

In some implementations of the method, the receiving the challengeresponse further comprises receiving, from the UE, uplink data.

In some implementations of the method, the transmitting the securitychallenge comprises transmitting, to the UE, an uplink grant and thesecurity challenge.

In some implementations of the method, wherein the transmitting theuplink grant and the security challenge comprises: transmitting, to theUE using radio resources based on a downlink grant, a random accessresponse, the security challenge, and an uplink grant for receiving thechallenge response.

In some implementations of the method, the transmitting the uplink grantand the security challenge comprises: transmitting, to the UE radioresources based on a downlink grant, a random access response and asecond downlink grant; and, transmitting, to the UE, and based on thesecond downlink grant, the security challenge and an uplink grant forreceiving the challenge response.

In some implementations of the method, the UEID and the uplink data arereceived with the challenge response.

In some implementations of the method, the UEID and the uplink data arereceived before the transmitting the security challenge.

In some implementations of the method, the serving node comprises anetwork function executing on a network node of the communicationnetwork.

In some implementations of the method, the serving node comprises aradio access network (RAN) node of the communication network.

In some embodiments, a method is provided for execution by a userequipment (UE) connected to a communication network. The methodincluding the UE: transmitting, to a serving node, an uplink messageincluding a UE identifier (UEID) comprising a shared session identifierfor a group of one or more UEs and a UE identifying component thatidentifies the UE within the shared session; receiving, from the servingnode, a security challenge; and, transmitting, to the serving node, achallenge response derived from at least the security challenge andcryptographic keying material associated with the shared session.

In some implementations of the method, the method further includes theUE transmitting, to the serving node, uplink data.

In some implementations of the method, before the transmitting the UEID,the message further includes: transmitting, to an initial node, anetwork attachment request.

In some implementations of the method, the method further includes theUE receiving, from the initial node, radio link configurationinformation including the UEID.

In some implementations of the method, the initial node comprises theserving node.

In some implementations of the method, the initial node comprises asdifferent network node from the serving node.

In some implementations of the method, the transmitting the uplinkmessage further includes transmitting uplink data.

In some implementations of the method, the transmitting the challengeresponse further includes transmitting uplink data.

In some implementations of the method, the receiving the securitychallenge includes the UE receiving, from the serving node, an uplinkgrant and the security challenge.

In some implementations of the method, the receiving the uplink grantand the security challenge further includes the UE receiving, from theserving node using radio resources based on a downlink grant, a randomaccess response, the security challenge, and an uplink grant fortransmitting the challenge response.

In some implementations of the method, the receiving the uplink grantand the security challenge further includes the UE: receiving, from theserving node using radio resources based on a downlink grant, a randomaccess response and a second downlink grant; and, receiving, from theserving node, and based on the second downlink grant, the securitychallenge and an uplink grant for transmitting the challenge response.

In some implementations of the method, the method further includes theUE transmitting the challenge response based on the uplink grant.

In some embodiments, a method is provided for execution by an anchornode of a communication network. The method including the anchor node:receiving, from a serving node: a UE identifier (UEID) comprising ashared session identifier for a group of one or more UEs and a UEidentifying component that identifies the UE within the shared session;an uplink data PDU destined for delivery on the communication network;and, a security challenge and a challenge response; deriving, from atleast the security challenge and cryptographic keying materialassociated with the shared session, an expected challenge response; and,if the challenge response matches the expected challenge response,transmitting, to another network node associated with the sharedsession, the uplink data PDU.

In some embodiments, a network function is provided. The networkfunction executing on a network node of a communication network to actas an anchor node, and the network node including: a network interfacefor receiving data from and transmitting data to network functionsconnected to a network; a processor; and a non-transient memory forstoring instructions that when executed by the processor cause thenetwork function to be configured to: receive, from a serving node: a UEidentifier (UEID) comprising a shared session identifier for a group ofone or more UEs and a UE identifying component that identifies the UEwithin the shared session; an uplink data PDU destined for delivery onthe communication network; and, a security challenge and a challengeresponse; derive, from at least the security challenge and cryptographickeying material associated with the shared session, an expectedchallenge response; and, if the challenge response matches the expectedchallenge response, transmit, to another network node associated withthe shared session, the uplink data PDU.

In some implementations, the uplink data PDU is transmitted to a userplane function executing on the other network node.

In some implementations, the anchor node comprises a network functionexecuting on a network node of the communication network.

In some implementations, the anchor node comprises a radio accessnetwork (RAN) node of the communication network.

In some embodiments, a method is provided for a serving node of acommunication network. The method including the serving node: receiving,from an anchor node: a shared session identifier that identifies ashared session for a group of one or more UEs, a target UE identifier(TID) that identifies one or more UEs from the group of UEs thatcomprise the shared session, downlink data, a security challenge, and anexpected challenge response derived from at least the security challengeand cryptographic keying material associated with the shared session;transmitting the security challenge and a paging notification associatedwith the TID; receiving, from a responding UE, a challenge response anda responding UE identifier (RID); and, if the challenge response matchesthe expected challenge response, and if the RID received from theresponding UE corresponds to the TID received from the anchor node,transmitting, to the responding UE, the downlink data.

In some implementations of the method, the serving node comprises a corenetwork function (CNF) executing on a network node of the communicationnetwork.

In some implementations of the method, the serving node comprises aradio access network (RAN) node of the communication network.

In some implementations of the method, if the challenge response matchesthe expected challenge response the method further includes the anchornode transmitting, to the anchor node, a delivery status reportindicating the UE has been validated and the downlink data has beentransmitted to the UE.

In some implementations of the method, before the transmitting thedelivery status report, the method may further include the serving nodereceiving, from the anchor node, a request to provide the deliverystatus report.

In some implementations of the method, if the challenge response matchesthe expected challenge response the method further includes the servingnode: receiving, from the UE, a UE status report indicating successfulreceipt of the downlink data by the UE; and, transmitting, to the anchornode, an indication of the UE status report.

In some implementations of the method, before the transmitting the UEstatus report, the method further includes the serving node receiving,from the anchor node, a request to provide the UE status report.

In some implementations of the method, if the challenge response doesnot match the expected challenge response the method further includesthe serving node transmitting, to the anchor node, a delivery statusreport indicating the UE was not validated.

In some implementations of the method, before the delivery status reportis transmitted, the method further includes the serving node receiving,from the anchor node, a request to provide the delivery status report.

In some implementations of the method, if the serving node does notreceive the challenge response, the method further includes the servingnode transmitting, to the anchor node, a delivery status reportindicating a failure to deliver the downlink data.

In some implementations of the method, the transmitting the securitychallenge and the paging notification further includes the serving nodetransmitting, to the UE, an uplink grant for receiving the challengeresponse.

In some implementations of the method, before the transmitting theuplink grant and the security challenge, the method further includes theserving node transmitting, to the UE, a downlink grant for receiving thesecurity challenge.

In some implementations of the method, the transmitting the uplink grantand the security challenge further includes the serving nodetransmitting, to the UE and based on the downlink grant, a random accessresponse, the security challenge, and the uplink grant.

In some implementations of the method, the transmitting the uplink grantand the security challenge includes the serving node: transmitting, tothe UE and based on the downlink grant, a random access response and asecond downlink grant; and, transmitting, to the UE and based on thesecond downlink grant, the security challenge and an uplink grant forreceiving the challenge response.

In some implementations of the method, the transmitting the securitychallenge and the paging notification includes the serving nodetransmitting a paging message including the security challenge.

In some implementations of the method, the transmitting the securitychallenge includes the serving node transmitting a random accessresponse including the security challenge.

In some embodiments, a method is provided for a user equipment (UE) of acommunication network. The method including the UE: receiving, from aserving node, a paging notification that identifies one or more UEs froma group of UEs that comprise a shared session and a security challenge;transmitting, to the serving node, a responding UE identifier (RID), anda challenge response based at least on the security challenge, andcryptographic keying material associated with the shared session; and,receiving, from the serving node, downlink data.

In some embodiments, a network function is provided. The networkfunction executing on a network node of a communication network to actas a serving node, and the network node including: a network interfacefor receiving data from and transmitting data to network functionsconnected to a network; a processor; and a non-transient memory forstoring instructions that when executed by the processor cause thenetwork function to be configured to: receive, from an anchor node: ashared session identifier that identifies a shared session for a groupof one or more UEs; a target UE identifier (TID) that identifies one ormore UEs from the group of UEs that comprise the shared session;downlink data, a security challenge, and an expected challenge responsederived from at least the security challenge and cryptographic keyingmaterial associated with the shared session; transmit the securitychallenge and a paging notification associated with the TID; receive,from a responding UE, a challenge response and a responding UEidentifier (RID); and, if the challenge response matches the expectedchallenge response, and if the RID received from the responding UEcorresponds to the TID received from the anchor node, transmit, to theresponding UE, the downlink data.

In some embodiments, a user equipment (UE) is provided. The UEcomprising a processor and non-transient memory including instructionsthat, when executed by the processor, render the UE operative to:receive, from a serving node, a paging notification that identifies oneor more UEs from a group of UEs that comprise a shared session and asecurity challenge; transmit, to the serving node, a responding UEidentifier (RID) a challenge response based at least on the securitychallenge and cryptographic keying material associated with the sharedsession; and, receive, from the serving node, downlink data.

In some implementations of the method, the method further includes theUE transmitting, to the serving node, a delivery status reportconfirming receipt of the downlink data.

In some implementations of the method, the receiving the securitychallenge includes the UE receiving, from the serving node, the securitychallenge, and an uplink grant for transmitting the challenge response.

In some implementations of the method, before the receiving the uplinkgrant and the security challenge, the method further includes the UEreceiving, from the serving node, a downlink grant for receiving thesecurity challenge.

In some implementations of the method, the receiving the uplink grantand the security challenge further includes the UE receiving, from theserving node using radio resources based on a downlink grant, a randomaccess response, the security challenge, and the uplink grant.

In some implementations of the method, the receiving the uplink grantand the security challenge further includes the UE: receiving, from theserving node using radio resources based on a downlink grant, a randomaccess response and a second downlink grant; and, receiving, from theserving node and based on the second downlink grant, the securitychallenge and an uplink grant for transmitting the challenge response.

In some embodiments, a method is provided for an anchor node of acommunication network. The method including the anchor node: receiving,from another network node associated with a shared session for a groupof one or more User Equipment (UEs), a downlink user data packet; and,transmitting, to a set of target network nodes associated with theshared session, a downlink PDU based on the downlink user data packet,wherein the downlink PDU is cryptographically protected usingcryptographic keying material associated with the shared session; anintended recipient that includes: a target UE identifier (TID) thatidentifies one or more UEs from the group of UEs that comprise theshared session, a security challenge, and an expected challenge responsederived from at least the security challenge and cryptographic keyingmaterial associated with the shared session.

In some embodiments, a network function is provided. The networkfunction executing on a network node of a communication network to actas an anchor node, and the network node including: a network interfacefor receiving data from and transmitting data to network functionsconnected to a network; a processor; and a non-transient memory forstoring instructions that when executed by the processor cause thenetwork function to be configured to: receive, from another network nodeassociated with a shared session for a group of one or more UserEquipment (UEs), a downlink user data packet; transmit, to a set oftarget network nodes associated with the shared session: a downlink PDUbased on the downlink user data packet, wherein the downlink PDU iscryptographically protected using cryptographic keying materialassociated with the shared session; an intended recipient that includes:a target UE identifier (TID) that identifies one or more UEs from thegroup of UEs that comprise the shared session; a security challenge, andan expected challenge response derived from at least the securitychallenge and cryptographic keying material associated with the sharedsession.

In some implementations of the method, wherein the intended recipientcomprises a list of TIDs to identify a plurality of UEs from the group.

In some implementations of the method, the intended recipient comprisesa paging identifier associated with one or more UEs of the group.

In some implementations of the method, the method further includes theanchor node receiving, from a network node from the set of targetnetwork nodes, a delivery status report indicating an outcome ofattempted delivery of the downlink PDU.

In some implementations of the method, the method further includes theanchor node receiving, from a network node from the set of targetnetwork nodes, a delivery status message indicating successful deliveryof the downlink PDU to the UE.

It will be understood that some embodiments of the present inventionprovide for a network function having a processor and memory storinginstructions that when executed by the processor cause the networkfunction to carry out the steps of the above described embodiments,implementations and methods described above. In further embodimentsthere are provided network functions composed of functional processingelements to carry out the steps of the above described methods.

It will be further understood that implementations are described abovein association with a particular embodiment. These implementationsshould be understood to be combinable with other implementations, and insome instances may be applicable with an embodiment other than the onethat they are described in conjunction with. There may be some cases inwhich implementations cannot be combined because they are mutuallyexclusive, but these scenarios will be readily understood and identifiedby those skilled in the art.

Although the present invention has been described with reference tospecific features and embodiments thereof, it is evident that variousmodifications and combinations can be made thereto without departingfrom the invention. The specification and drawings are, accordingly, tobe regarded simply as an illustration of the invention as defined by theappended claims, and are contemplated to cover any and allmodifications, variations, combinations or equivalents that fall withinthe scope of the present invention.

1.-28. (canceled)
 29. A method for execution by user equipment (UE) of aradio access network (RAN), the method comprising: transmitting, to aserving node of the RAN, an uplink transmission, the uplink transmissionincluding a UE identifier (UEID), a session identifier that identifies ashared session for a group of one or more UEs, and uplink user planedata; receiving, from the serving node, a downlink transmission, thedownlink transmission including a security challenge; deriving achallenge response from at least the security challenge andcryptographic keying material associated with the shared session; andtransmitting, to the serving node, the challenge response.
 30. Themethod according to claim 29, wherein the uplink transmission includes arandom access preamble and the downlink transmission includes a randomaccess response, the random access response including the securitychallenge and an allocation of uplink radio resources for transmissionof the challenge response.
 31. The method according to claim 29, whereinthe uplink transmission includes a random access preamble and thedownlink transmission includes a random access response, the randomaccess response including an allocation of downlink radio resources fora further downlink transmission, the further downlink transmissionincluding the security challenge and an allocation of uplink radioresources for transmission of the challenge response.
 32. The methodaccording to claim 29, wherein the uplink transmission includes alogical channel identifier (LCID) and the session identifier includesthe LCID.
 33. A User Equipment (UE) of a radio access network (RAN), theUE comprising: a radio interface; a processor; and a non-transitorymemory for storing instructions that when executed by the processorcause the UE to be configured to be operable to: transmit, using theradio interface, an uplink transmission, the uplink transmissionincluding a UE identifier (UEID), a session identifier that identifies ashared session for a group of one or more UEs, and uplink user planedata; receive, using the radio interface, a downlink transmission, thedownlink transmission including a security challenge; derive a challengeresponse from at least the security challenge and cryptographic keyingmaterial associated with the shared session; and transmit, using theradio interface, the challenge response.
 34. The UE according to claim33, wherein the uplink transmission including a random access preambleand the downlink transmission including a random access response, therandom access response including the security challenge and anallocation of uplink radio resources for transmission of the challengeresponse.
 35. The UE according to claim 33, wherein the uplinktransmission includes a random access preamble and the downlinktransmission includes a random access response, the random accessresponse including an allocation of downlink radio resources for afurther downlink transmission, the further downlink transmissioncomprising the security challenge and an allocation of uplink radioresources for transmission of the challenge response.
 36. The UEaccording to claim 33, wherein the UEID includes a session identifyingcomponent and a UE identifying component and the session identifierincludes the session identifying component.
 37. The UE according toclaim 33, wherein the uplink transmission further includes a logicalchannel identifier (LCID) and the session identifier includes the LCID.38. A system comprising a serving node and an anchor node, the servingnode configured to: receive from a user equipment (UE), an uplinktransmission, the uplink transmission including a UE identifier (UEID),a session identifier that identifies a shared session for a group of oneor more UEs, and uplink user plane data; transmit to the UE, a downlinktransmission, the downlink transmission including a security challenge;receive from the UE, a challenge response to the security challenge; andtransmit to an anchor node associated with the UEID, an uplink RANprotocol data unit (PDU), the uplink RAN PDU including the UEID, thesession identifier, the uplink user plane data, the security challengeand the received challenge response; and the anchor node configured to:derive an expected challenge response from at least the securitychallenge and cryptographic keying material associated with the sharedsession; and, transmit to another network node, the uplink user planedata after determining that the received challenge response matches theexpected challenge response.
 39. The system according to claim 38,wherein the uplink transmission includes a random access preamble andthe downlink transmission includes a random access response, the randomaccess response including the security challenge and an allocation ofuplink radio resources for transmission of the challenge response. 40.The system according to claim 38, wherein the uplink transmissionincludes a random access preamble and the downlink transmission includesa random access response, the random access response including anallocation of downlink radio resources for a further downlinktransmission, the further downlink transmission including the securitychallenge and an allocation of uplink radio resources for transmissionof the challenge response.
 41. The system according to claim 38, whereinthe UEID includes a session identifying component and a UE identifyingcomponent and the session identifier includes the session identifyingcomponent.
 42. The system according to claim 38, wherein the uplinktransmission includes a logical channel identifier (LCID) and thesession identifier includes the LCID.